Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Nov 2000 11:54:58 -0700 (MST)
From:      Nate Williams <nate@yogotech.com>
To:        Mike Smith <msmith@FreeBSD.ORG>
Cc:        arch@FreeBSD.ORG, dillon@earth.backplane.com
Subject:   Re: The shared /bin and /sbin bikeshed 
Message-ID:  <200011111854.LAA04008@nomad.yogotech.com>
In-Reply-To: <200011110315.eAB3Fp909237@mass.osd.bsdi.com>
References:  <200011110257.eAB2vj034258@vashon.polstra.com> <200011110315.eAB3Fp909237@mass.osd.bsdi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> > But to keep things in perspective, saving RAM isn't really the main
> > advantage of shared libraries.  Their value lies in other areas.  They
> > save a lot of disk space; they allow bugs to be fixed in many programs
> > at once via the installation of a single repaired library; and they
> > provide the flexibility of run-time modules ("plug-ins"), which are
> > used by more and more software packages these days.
> 
> It would be interesting to know whether the speed overhead (if any) for 
> PIC code is offset by the improved cache behaviour as well.

Benchmarks done early on tend to say that using PIC code is 10-15%
slower than not.  For awhile, GCC's internal compiler libraries were
compiled shared, but the speedups from compiling them static were
significant enough to show static linking is *significantly* faster than
shared linking, even if you remove the startup issues.

My own benchmarks show (pre-ELF) this as well.


Nate


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




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