8904 - Linux x86 .so are bloated

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[bobj]

Linux x86 .so's have become bloated from M6 to M7.

Look at liblwbrk, nslocale, strres and uconv.  These have changed
little since M6.  And no similar bloat was seen on Win or Mac from M6 to M7.
(Although there still is the Windows M5 to M6 bloat bug #7748 outstanding.)

    liblwbrk.so  nslocale.so  stres.so  uconv.so
M6:  15496        27512        10980     44852
M7:  31982        48150        28113     83280

What happened to the intermediate M7 builds?  To track down the Windows
bloat problem, I went back and looked at the size.txt files for the
intermediate M6 builds until I found the day that the bloat began.
We need to do that for Linux M7 builds.

Comment 1

[chris hofmann]

lets get the man, the legend, to look at this...

Comment 2

[chris hofmann]

we need to get this figured out in m8 if we can

Comment 3

[Chris Yeh]

we discovered a problem where the opt bits were not getting stripped properly.

this should have been fixed for today's verification builds. can someone please
look and verify that the *.so's are back to their old, relatively svelte selves?

Comment 4

[Brian Ostrom]

Today's Linux build is back down to about 5.5MB.  I'm stripping the
right files now, so I think this is fixed.

Comment 5

[Phil Peterson]

I'm happy to hear that, but I wish we had "size matters" output for Linux so I
could eyeball it myself.

Comment 6

[bobj]

Me too!  Even the old size files have disappeard.

Comment 7

[Chris Yeh]

the break happened when we transferred the build responsibilities from donm (who
has since left the company) to briano.

spoke to briano today about reinstituting the reporting automation. so it should
be soon.

Comment 8

[Brian Ostrom]

Okay whiners, starting tomorrow (7/3) the build script will generate
a sizes.txt for each successful build.  This'll end up in the appropriate
directories on sweetlou.  I tried to make it look reasonable, but feel
free to send me your opinions.

Comment 9

[bobj]

<WHINE>Previously sizes.txt was sorted alphabetically which made it much easier
to find things. </WHINE>

Comment 10

[bobj]

The sizes are better, but they still seem to be larger than before.

                  liblwbrk.so  nslocale.so  strres.so uconv.so
M6:                15496        27512        10980     44852
M7:                31982        48150        28113     83280
1999-07-06-08-M8/
sizes.txt:         18352        30280        15128     55816

Comment 11

[Chris Yeh]

You yourself said "These have changed little since M6." but they _have_ changed,
right? There was code checked in to these dll's that might have caused size
difference.

A doubling of size is worth investigating, especially since it was a sudden jump.
But this appears to be additional code in the course of development.

Bob, can you have your engineers quantify the changes they made to these dll's
between M6 and now? If they have checked in additional code, since then, a 15%->
20% size jump is not unreasonable.

Comment 12

[Brian Ostrom]

I've made a change to the build script which will sort the sizes.txt
file as you wanted.

As for the bloat, I really don't know what to say.  I've done everything
I can with respect to reducing the size of each file in the downloadable
package, and I can assure you that the actual build mechanism used is the
same as when Don was doing the builds.  One of the problems with many (all?)
C++ compilers is they generate huge object files relative to the actual
source.  Perhaps, given that, even a small amount of new code could account
for the perceived bloat in the binaries/libraries...?

I really don't know what else I can do....

Comment 13

[Brian Ostrom]

No one has given me any reason to believe I've not done something
I should've, or that I've done something wrong, so I'm gonna close
this sucker again and hope for the best.

Comment 14

[Hallvard B Furuseth]

To reduce bloat from g++, put
  #ifdef __GNUG__
  # pragma interface "dirname/filename.h"
  #endif
at the top of .h files that declare classes and inline functions.
That'll prevent static copies of the vtables & so on from being made in
each file which uses the .h file.
For each .h file which has #pragma interface, put
  #ifdef __GNUG__
  # pragma implementation "dirname/filename.h"
  #endif
at the top of a .cpp file which #includes the .h file and is linked by all
programs that use the .h file.  This file will get external defs of the
vtables & so on.  See Info node (gcc)C++ Interface.

To get only one instance of each template you use under g++, explicitly
instantiate them in one file, and use one of several options from Info node
(gcc)Template Instantiation to get rid of all other (static) instances.

Comment 15

[bobj]

chofmann,  Is [e-mail] owning this, or should this be
reopened and reassigned?