Our bloat problem [LWN.net]

Our bloat problem

Posted Aug 4, 2005 9:04 UTC (Thu) by rakoch (guest, #4666)
Parent article: Our bloat problem

On Windows one usually specifies which symbols get exported while on Linux
the default is that everything gets exported. Reducing the number of
symbols in the library can make loading an application significantly
faster since fewer symbols need resolving. I wonder how much faster
OpenOffice will load when using this
patch to GCC:
http://www.nedprod.com/programs/gccvisibility.html
and explicitly specify in the code which class is private to the library
and which is public.

-Rudiger

(Log in to post comments)

.so vs DLL

Posted Aug 4, 2005 9:59 UTC (Thu) by eru (subscriber, #2753) [Link]

On Windows one usually specifies which symbols get exported while on Linux the default is that everything gets exported.

Linux (or rather the linker and run-time loader) works hard to make shared library programming and usage as similar as possible to using static libraries. If I remember correctly from past life, on Windows writing and building a shared library ("DLL") requires special care ,and you can easily share only functions. This makes the run-time mechanism much simpler and faster to load.

Our bloat problem

Posted Aug 6, 2005 22:30 UTC (Sat) by nix (subscriber, #2304) [Link]

KDE can already use the visibility attributes (available in GCC 4 without the need to patch).

I'm not sure if OOo can use them, but if it can't, it should. :)

gcc4's -fvisibility=hidden

Posted Aug 12, 2005 13:58 UTC (Fri) by ringerc (guest, #3071) [Link]

Support for this should be *REALLY* easy to add to a library that works under win32, or an app that already supports plug-ins under win32. You can piggyback the required attribute directives on the win32 export macros.

It does help, and is well worth doing since in many cases it won't require much more than tweaking the export macros in a header, then scratching together some more m4 macros for your configure scripts.