woods@weird.com (Greg A. Woods) writes:

 Few months ago (in October, I believe) somebody from Cygnus posted
 in binutils mailing list a detailed report about speeding up the
 loading of shared libraries in Linux. If my memory serves well, the
 real reason of this inefficiency is that GNU ld does not perform
 any optimisations when processing the object code during the
 linking which results in extremely inefficient executable binaries,
 it can be clearly seen when loading a big C++ application linked
 against bunch of shared libraries. The approach might be
 incorporated into one of the forthcoming releases of binutils and
 requires some modifications inside GNU ld. As a result, the overall
 loading time has vastly reduced and, for example, KDE with its
 enormous pack of shared libraries now starts just in a moment. 
 Details can be easily found in their mailing list archive.

>> what incredibly complicated operations ld-elf.so is doing to link
>> such simple programs (containing minimal set of references to
>> libs) to do it so long?
>
> If you don't already know, you probably don't want to know.  It's
> really quite a sick and horrid and inefficient hack the way
> dynamic libraries work on SunOS-4 and now BSD for ELF binaries.
> I've thought so since day one (although back then I had a secret
> desire for making programs extensible with machine code instead of
> interpreter code), and now that I understand the security
> implications more deeply, I'm even more certain of it (and my
> secret desire for more and easier extensibility has been mostly
> quelled).  That's not to say there are not some specific scenarios
> and some types of workloads which can benefit greatly from such
> hacks (i.e. turn the performance disadvantages into significant
> advantages), but....  :-)
>
> See my archived postings (to current-users, I think) about just
> how much faster my all-100%-static-linked NetBSD/sparc machine is
> (even/especially with X11!).

Oleg