Recent versions of OpenOffice/StarOffice exhibit an disturbing increase in shared library file size. This is especially true for the Unix platforms, topped by whopping 73% increase from SRC569 to SRC624 on Linux.
The biggest increase in code size especially on GCC based platforms is probably due to the increased use of exceptions. Since abandoning exceptions is out of question we can't do much about this currently. It's interesting to note that the use of exception specifications which should in principle help reducing the costs of exception handling has a pretty averse effect on GCC platforms. Exception specifications increase the code size of callees by a significant amount (up to 300 bytes for GCC/Linux/X86 per method!), without having a noticeable effect on the code size of the caller. Even the empty exception specification throw() applied to a leave (non calling) function incurs this cost. This is clearly a very pronounced deficiency of GCC.
Remove all exception specifications, especially on all inline
functions. This seems to be the only possible way to reduce the code
size of gcc-2.95.2 build libraries significantly.
Some
preliminary evaluation of gcc-3.0 indicates that the gcc developers
noticed this problem. Gcc-3.0 offers a switch which allows the
compiler to not to enforce the exception specifications.
Additionally the compiler is much more able in recognizing that
some functions will never throw and produces way smaller code in
this case even in the case of honored exception specifications. It
might be very worthwhile to switch to gcc-3.0 when it's ready.
Gcc-3.0 is scheduled to be available at the end of the 1Q 2001. The
downside of Gcc-3.0 will be that it's in no way binary compatible to
gcc-2.95.2
Update 2000/05/28: gcc-2.95.3 (bugfix release) seems to produce more compact code in some cases. It has not yet been investigated if this improvement is related to exception specifications. Anyway, improvements from 0.4% up to 20% can be observed. Preliminary tests have been done on SRC633, details can be found here.
Export minimized shared libraries could be smaller on
GCC/GNU-binutils platforms. The GNU ld has a deficiency regarding
minimizing the .dynstr section of a shared library if version map
are used to minimize the exports from the library. All it's does is
to remove the references of the "localized" strings from
the .dyntab, but it never deletes the strings itself from the
.dynstr section. Neither does "strip".
The Mozilla
developers noticed this, too. They invented a small tool called
"elf-gc-dynstr" which removes the unused strings and than
relocates the references to the remaining stuff in the .dyntab
section. Some tests showed that this operation has no side effects
and does reduce the overall size of the *.so files by about 2.5% to
3.5%.
size of all stripped *.so in kBytes |
SRC569 |
SRC624 |
---|---|---|
without elf-gc-dynstr treatment |
116898 |
202844 |
with elf-gc-dynstr treatment |
114409 |
195756 |
The more export minimized shared libraries ( components! ) we
have the more will be the overall savings.
We use
elf-gc-dynstr on unxlngi3 since SRC625 b
Patched GCC called "FrankenGCC". Another offshot of
Mozilla, can be found here.
GCC tends to the create a vtable even in the case of a class
with only pure virtual methods. Another problem is that certain
inlined static constructs end up in every object file but not in the
link-once section. Thus ld fails to combine these constructs at
shared library link time.
I tried the patch but didn't see
any improvement in code size. The opposite was true, the file size
did even increase.
SRC624 stripped libcfgmgr2.so |
gcc-2.95.2 |
frankengcc-2.95.2 |
---|---|---|
library size in kBytes |
6084924 |
6422940 |
Author: Jens-Heiner Rechtien
Last changed: 16.03.2001