[opensuse-packaging] Easy way to optimize startup time
Hi, for a few weeks now openSUSE Factory has a binutils which supports -Bsymbolic-functions. This option causes global symbol references inside a shared object to be resolved locally if that is possible, e.g. if a shared library calls within one of its functions another exported function that is defines itself, then that one is encoded via a local relative jump, rather than going through the complicated and slow ELF semantics. This does break if an application is interposing a symbol, e.g. tries to replace one of the libraries public functions by one it defines by its own and expects the library to call the one the application provides. This is however rare and usually even is an unintended symbol clash. So, whats the advantage? of course that depends on the library type: C++ benefits a lot more than plain C libraries. I've tested it however successfully against small c libraries (e.g.) ncurses or dbus-1 as well as big c++ libraries (libzypp, boost, libstdc++,qt3). For e.g. ncurses it resulted in a 1.2% disk space saving and roughly 25% reduced relocation time (granted, its only measurable via LD_DEBUG=statistics). For qt3, it results in a 38% relocation time improvement and a 5.5% disk space saving. So, in short: if you know what you're doing, then use $LDFLAGS=-Wl,-Bsymbolic-functions Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 5 Apr 2007, Dirk Mueller wrote:
for a few weeks now openSUSE Factory has a binutils which supports -Bsymbolic-functions. This option causes global symbol references inside a shared object to be resolved locally if that is possible,
And it should be noted, that unlike the frowned upon -Bsymbolic (now forget that you read that flag name!) it doesn't inherently break exception handling for C++, as it only applies to STT_FUNC symbols (associated with, you guessed it, functions, i.e. symbols for code), not to data symbols.
This does break if an application is interposing a symbol, e.g. tries to replace one of the libraries public functions by one it defines by its own and expects the library to call the one the application provides.
This is however rare and usually even is an unintended symbol clash.
That is true. There are some cases though, where interposition is consciously used. For instance by libpthread. It's also explicitely allowed to override the global operator new and delete (in C++). Both cases matter only when building glibc or libstdc++, so you don't need to care. Interposition is sometimes also used for quick hacks or work-arounds (e.g. catching open/close by some LD_PRELOAD module). That breaks for all symbols exported by libraries compiled with that option (only for references to them from that library internally to itself). Catching open/close and other glibc functions will continue to work. And ltrace won't work anymore as expected: all such internal calls won't be noticed (cross module calls, e.g. from application to library will continue to be intercepted).
So, in short: if you know what you're doing, then use
$LDFLAGS=-Wl,-Bsymbolic-functions
Yes. But please: it does interfere with a very low level concept of how our shared libraries work. It should be treated accordingly, i.e. please test extensively before using that option. One can't test the effect of this option by 100% (as you can't know all users of your shared library). A last point: this option only matters for shared libraries, so don't bother with it when you don't have any. Apart from these concerns it can bring some nice speedups in relocation time without too much hassle. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (2)
-
Dirk Mueller -
Michael Matz