This is the mail archive of the
mailing list for the glibc project.
Re: Speeding up the dynamic linker with 100s of DSOs?
- From: michael meeks <michael dot meeks at novell dot com>
- To: Andrew Chatham <chatham at google dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Wed, 25 Jan 2006 17:05:51 +0000
- Subject: Re: Speeding up the dynamic linker with 100s of DSOs?
- Reply-to: michael dot meeks at novell dot com
So - we have the same problem in OO.o - but we have 'only' 150DSOs
loaded instead of 300 almost all dlopened.
I have several patches addressing this posted to the binutils list -
particularly implementing -Bdirect linking (which stores the
compile-link-time information as to which library a symbol is defined
in) so that we can look there 1st at run-time. That of course, removes
75% or so of the O(num-libraries) lookups from the link.
Of course - a facile implementation of -Bdirect would have serious
problems with C++ - because of the vague linkage / ODR issues - so, the
patch detects which symbols are vague during library compile/link, then
propagates that information to other libraries, so life is good.
In addition; by sorting relocations & dynsym & dynstr entries one can
get another ~25% win, and by storing & comparing pre-computed hash
values one can get a ~50% win - so, all in all if we could get this
stuff into general glibcs ;-), performance of large, modularized C++
apps would get a lot better. [ there are 2 final, more maginal tweaks
queued pending this getting rationalized too :-].
The latest patches .suse.ized are at:
As one blogs about the work, I've had the Troll-tech guys & a random
ISV play with various features - suffering the same problems. I'd love
to know what your experience of testing these is - that is if you are ok
with re-building your glibc :-)
 - the other 25% of relocations in my case being vague type info.
 - SL 10.1 should ship with some of this, though it's not there yet.
email@example.com <><, Pseudo Engineer, itinerant idiot