464671 - move to static builds for SeaMonkey nightlies and releases

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Robert Kaiser]

As long as we can't go libxul with SeaMonkey, we should at least move to static builds for nightlies and releases, which speeds up startup for users by not loading too many different files.

I'm marking all bugs as dependencies that I found in the SeaMonkey product regarding static builds, we still need to verify they still apply.

Comment 1

[Steve Snyder]

I can confirm that for the released SM 2.0a2 in Win32:

1. SM builds statically (with VS2005/SP1) and runs mostly correctly.  The only observed exception being:

2. Zoom-in/zoom-out pointers missing as described in bug 389448.

Note that I don't use SM mail/news so this component may have problems I haven't seen.

Comment 2

[Karsten Düsterloh]

(In reply to comment #0)
> speeds up startup for users by not loading too many different files.

Is this really an issue?
Do you have numbers about the gain?

Comment 3

[(not currently active) Ted Mielczarek]

bug 345517 (enabling libxul for Firefox) mentions perf gains, but I can't find an actual record of them. I'm sure if you can dig up the bug where Firefox was originally built --enable-static you could find the perf gains there as well.

Comment 4

[Robert Kaiser]

We unfortunately don't have any SeaMonkey perf numbers any more, and I don't know how to easily test startup perf on my machine (where I've been doing both shared and static builds for testing reasons for some time), but I know that back when we still had numbers (from tinderbox), we felt that difference a lot (back in the dark age when we moved flat chrome to jarred chrome we even felt that as opening/accessing fewer files on disk is faster).

Comment 5

[Steve Snyder]

(In reply to comment #2)
> (In reply to comment #0)
> > speeds up startup for users by not loading too many different files.
> 
> Is this really an issue?
> Do you have numbers about the gain?

18 months old, but still pertinent:

http://forums.mozillazine.org/viewtopic.php?f=6&t=590138

Comment 6

[Mark Banner (:standard8)]

Somewhere around I've an extension for Thunderbird that I used for manual startup time testing (although it could be used for automation with some infrastructure as well). It could probably be quite easily adapated for testing startup (or maybe see if you can rip off some of the talos infrastructure which would possibly be simpler).

Comment 7

[Robert Kaiser]

The "standalone talos" stuff exists: https://wiki.mozilla.org/StandaloneTalos
It probably need some modification (hopefully mostly config) to run SeaMonkey instead of Firefox, but I'd be happy if someone could test startup perf with in on both static and shared builds.

Comment 8

[Robert Kaiser]

I have enabled this in the experimental new comm-1.9.1 SeaMonkey-Ports buildbots, they should be producing static nightlies from now on, while their dep (and unittest) builds stay shared. If someone has means for comparing their speed with those of the comm-central nightlies (which are still shared), I'd be glad to see those numbers.

Comment 9

[Robert Kaiser]

As we now have the first statically built nightlies, here is a comparison of the build package (download) sizes of the shared nightlies from the old buildbots and the static ones from the new buildsbots:

comm-central (shared) vs. comm-1.9.1 (static)

Mac dmg: 24048516 vs. 22371064 bytes (7% reduction)
Linux .tar.bz2: 14324466 vs. 12905567 bytes (10% reduction)
Windows .exe: 10642509 vs. 10353942 bytes (3% reduction)
Windows .zip: 15348896 vs. 14680236 bytes (4% reduction)

Note that Mac is a Tiger vs. a Leopard build, but the shared hourly build of the Leopard machines give us almost the same size as the Tiger nightlies, so the reduction should be quite accurate.
Additionally, Windows also doesn't have PalmSymc in the static builds any more as it caused linking problems, so the difference calculated here is slightly larger than what it would usually be, even though that extension is relatively small.

I'd like to see speed (Ts?) comparisons between the latest-comm-central and latest-comm-1.9.1 nightlies to see what this mean in terms of performance.

Comment 10

[Mark Banner (:standard8)]

Note before you can move this onto the non-experimental boxes, removed-files.in and the packages files need updating - otherwise the updaters won't remove the old files, and there will be a mix of dlls etc about.

Comment 11

[Robert Kaiser]

true, we have to do update removed-files.in, you're right there, we need to removed the shared libs on people's computers.

I'm not sure what you mean in terms of packages, as we are actually packaging up everything well in both cases, what changes do you think we need there?

Comment 12

[Robert Kaiser]

Current nightlies run statically, and release mozconfigs are set for that as well, so marking this fixed. From a release POV, 2.0b1 will be the first hg-based release to do that.