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
Description: This is a digitally signed message part.