Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Oct 2002 15:43:45 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Peter Wemm <peter@wemm.org>
Cc:        Dan Nelson <dnelson@allantgroup.com>, Doug Rabson <dfr@nlsystems.com>, Nate Lawson <nate@root.org>, current@FreeBSD.ORG
Subject:   Re: libc size
Message-ID:  <3DC06EB1.CCF3B30D@mindspring.com>
References:  <20021030233106.32D292A896@canning.wemm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote:
> > Note that dynamically-linked executables take significantly longer to
> > exec than statically-linked ones.
> 
> Indeed yes.  Running ld-elf.so.1 isn't free.   Also, calling PIC libraries
> isn't free either.  Not only that, but even fork(2) is slower when you come
> *from* a dynamic executable.

I can't tell if he's complaining about runtime costs, or startup
costs.

Much of the runtime cost can be gotten rid of by thunking the code,
at the expense of dirting the pages that make the references by
replacing their reference targets with the addresses of the real
functions.  That's way overboard, for my tastes, but it's possible
to remove the indirection overhead that way.

The PIC overhead is likely unavoidable.  I'd actually like to see
the "benchmark" run on statically linked PIC vs. non-PIC code, so
we can assign the proper portion of the blame for "PIC-ness".  IMO,
the cost is actually very small, given that you have to go over a
64K boundary before it becomes really expensive; relative branches
are very common in non-PIC code.

I think the expense in the the LD_PRELOAD treatment, and in the
finding and mapping of the ld.so and library images... and that was
designed to be avoidable by the ELF designers, even if most OSs
never chose to properly implement it, and wedged ld.so loading into
crt0, instead.


> But for /bin/sh, then ~user etc doesn't work too well when your account
> exists only somewhere like ldap.  Just like /bin/ls -l doesn't show the
> user and groups.
> 
> Fortunately the costs associated with this are mostly one-off per exec and
> are mostly lost in the noise when the commands being run are doing real
> work.

I agree.  If you are concerned about the overhead, then at least
assign the blame to the proper place; but for the most part, the
concern is unwarranted.


> In the days of monsters like mozilla, kde, gnome, gcc-3.x etc, dynamic
> binary exec times seem to be the least of our worries. :-(

AMEN.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC06EB1.CCF3B30D>