Skip to content

start:

Excessive shared libraries file sizes

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.

Reasons

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.

Solutions

  1. 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.

  2. 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

  3. 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