Em Quarta-feira 11. Novembro 2009, às 03.54.53, nf2 escreveu:
> On my system, Gtk+ links 44 libraries. I guess one less or more won't
> make any difference. Or, for instance a "gvfs-ls /" , which probably
> has to load about 15 libraries, takes 0.03 seconds. Therfore - I
> reckon - gathering unrelated APIs into a single *.so won't have any
> significant performance benefit. But maybe i'm wrong.
Actually, it does.
There's a performance penalty in loading each library, plus a combined penalty
of symbol resolution. Remember that each library has a different symbol
resolution search order, so the dynamic linker needs to keep the map for each
library. And the more libraries you have, the more libraries you have to walk
through with failed resolutions before you reach the library that provides the
symbol you're searching for.
Moreover, inter-library symbol dependency requires expensive relocations. When
it's inside the same library, a cheaper absolute relocation is possible. This
affects more C++ code (the vtables) than C code (which would go through lazy-
binding PLT), but still affects enough to be relevant.
There used to be some tools to measure the ELF hashing performance, as well as
the average number of lookups to reach the conclusion of undefined symbol. I'm
sure Ulrich Drepper's DSO Howto paper has some more information.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Attachment:
signature.asc
Description: This is a digitally signed message part.