Subject: Re: dynamic linker
To: Greg A.Woods <email@example.com>
From: Oleg Polyanski <Oleg.Polianski@clear.co.nz>
Date: 03/20/2002 15:15:04
firstname.lastname@example.org (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!).