408430 - The file size of PreferencePanes has increased twentyfold.

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Eiichi]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.12pre) Gecko/20071214 Camino/1.6b1pre (like Firefox/2.0.0.12pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.12pre) Gecko/20071214 Camino/1.6b1pre (like Firefox/2.0.0.12pre)

Since 12/14/07, "Camino.app/Contents/PreferencePanes" of my own branch build has increased by 2000% to 8.5MB.
After cleaning my tree, that's the same result.
Related with fixing Bug 383934?

Mac OS X Version: 10.4.11 (Build 8S2167)
XCode Version: 2.5

For example,
12/13/07                 12/14/07  
-Camino.app/Contents/PreferencePanes:
454,254 bytes     -->  8,789,896 bytes

-/Appearance.prefPane/Contents/MacOS/Appearance:
47,592 bytes     -->   1,091,260

Reproducible: Always

Comment 1

[Eiichi]

. $topsrcdir/camino/config/mozconfig

mk_add_options MOZ_MAKE_FLAGS=-j4
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@

ac_add_options --enable-reorder
ac_add_options --enable-strip
ac_add_options --enable-static
ac_add_options --enable-static-libs
ac_add_options --enable-pthreads
ac_add_options --enable-optimize="-O3 -march=i686 -fforce-addr -msse3 -mfpmath=sse"

ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --disable-shared

Comment 2

[Mark Mentovai]

It's true, I confess.  I've totally restructured the way preference panes are built.  Well, it wasn't just me, I've had some help from Stuart.  But our work has actually decreased the size of the preference panes.

The PreferencePanes directory in the official 1.6b1pre (1.8 branch) nightly from Monday (2007121000) is 784kB.

The PreferencePanes directory in today's official 1.6b1pre (1.8 branch) nightly, 2007121400, is 740kB.

The PreferencePanes directory in the most recent cb-xserve01-1.6-M.18 tinderbox buid is 720kB.

The PreferencePanes directory in my own x86-only current 1.6b1pre (1.8 branch) builds is 568kB.  ppc-only, 552kB.

That's right.  Stuart and I have been busy.

Similarly, we haven't noticed any increase in the dmg download size.

I really have no idea what's going on with your builds, but I can say with authority that it hasn't affected my own builds (Xcode 3.0 and 2.5 on 10.5.1) or the official builds (Xcode 2.5 on 10.4.11).  If you're handy with nm, you can try to figure out what else is being included in your build that didn't used to be there, but other than that, I don't think there's really much we can do here.

Comment 3

[Stuart Morgan]

$ ls -lh
-rwxr-xr-x   1 stuartmo  502       1M Dec 14 16:11 Appearance
$ strip -x Appearance 
$ ls -lh
-rwxr-xr-x   1 stuartmo  502    41K Dec 14 16:20 Appearance

Clearly I'm not getting stripping on the pref panes anymore (in my standard
objdir builds). This is in both camino/build and /dist.

Comment 4

[Stuart Morgan]

Attachment: fix

Since we only strip during copy and the pref panes aren't part of a copy phase any more, I'm not sure how you and the tinderboxen are getting stripping, but this fixes me and seems like the right approach for the new model.

Comment 5

[Mark Mentovai]

Comment on attachment 293235 [details] [diff] [review]
fix

The tinderbox strips during packaging.  I don't know why I wasn't seeing this in my (should be equivalent to a tinderbox) -g build.

This seems like it might strip stuff too early?  We need to get the debugging symbols to talkback/breakpad.

Comment 6

[Eiichi]

Confirmed.
After applying an attachment (id=293235), the file size of PreferencePanes of my own build reduced to 410,031 bytes.

Comment 7

[Mark Mentovai]

Stuart or Eiichi or both, can you show me how xcodebuild is being invoked when Camino is made?  It'll look something like this:

/usr/bin/xcodebuild -project Camino.xcodeproj -target CaminoStatic -configuration Deployment GCC_VERSION="4.0" SYMROOT=build SDKROOT="/Developer/SDKs/MacOSX10.4u.sdk" MACOSX_DEPLOYMENT_TARGET="10.4" GCC_MODEL_TUNING= OPTIMIZATION_CFLAGS="-O2"

You can "make -w -C objdir/camino" if you don't have a build log handy, and you'll see a line like this in the output.

Comment 8

[Stuart Morgan]

For the i386 side:
/usr/bin/xcodebuild -project Camino.xcodeproj -target CaminoStatic -configuration Deployment GCC_VERSION="4.0" SYMROOT=build ARCHS="i386" SDKROOT="/Developer/SDKs/MacOSX10.4u.sdk" MACOSX_DEPLOYMENT_TARGET="10.4"

Comment 9

[Eiichi]

/usr/bin/xcodebuild -project Camino.xcodeproj -target CaminoStatic -configuration Deployment GCC_VERSION="4.0" SYMROOT=build ARCHS="i386" SDKROOT="/Developer/SDKs/MacOSX10.4u.sdk" MACOSX_DEPLOYMENT_TARGET="10.4" GCC_MODEL_TUNING= OPTIMIZATION_CFLAGS="-O3 -march=i686 -fforce-addr -msse3 -mfpmath=sse"

Comment 10

[Mark Mentovai]

Xcode 2.x ld generates huge __LINKEDIT sections when used with -bundle_loader.  It looks like the __LINKEDIT section has a copy of each symbol name from the main executable.  This doesn't happen with Xcode 3.0.  The bloat is worst when working with a static Camino, because their symbol tables are much larger.  When I initially looked at this with Xcode 3.x, I was using a nonstatic build, and didn't see much of a problem.

This isn't a problem for shipped builds, because those are run through strip when the package is built.  strip brings the __LINKEDIT section down to a reasonable size.

The best way I've found to bring these down to a reasonable size is to run strip -X.  That's an obsolete option intended to remove local symbols beginning with 'L'.  There aren't any of those in the output by the time we'd strip anyway, because ld strips them out itself.  By telling strip to strip something that isn't actually there, it'll make a pass over the file, leaving symbol table entries for global symbols and even local symbols and debugging symbols intact.  That's good for tinderbox builds and your own local debug builds.  When strip runs, it'll rewrite the __LINKEDIT section, producing a much smaller Mach-O file.  That's good for everyone.

Comment 11

[Mark Mentovai]

Attachment: strip -X

This is how you make Xcode do that.

I'm checking this in now to help everyone reclaim a few precious megabytes of disk space, so that makes this a TBR.

Comment 12

[Mark Mentovai]

This dropped the PreferencePanes directory on an x86 static build using Xcode 2.5 from 9,592kB to 568kB.

That's closer to 17-fold.  Sorry.

Comment 13

[Eiichi]

After landing an attachment (id=293257), the file size of PreferencePanes of
my own build reduced, but it is still 5,650,509 bytes.

Comment 14

[Stuart Morgan]

Comment on attachment 293257 [details] [diff] [review]
strip -X

Looks good.

Eiichi, you'll need to do a clean build of the pref panes, since this doesn't appear to trigger a rebuild itself. Probably you had a few pref panes rebuild due to other changes, giving you the partial reduction.

Comment 15

[Eiichi]

Thanks, Stuart.
Cleaning my tree has resolved the problem.

Mark & Stuart, thanks for your quick fix, even though you are very busy.