Date: Tue, 1 May 2012 09:55:30 -0400 From: Gary Palmer <gpalmer@freebsd.org> To: Erik Cederstrand <erik@cederstrand.dk> Cc: freebsd-current FreeBSD <freebsd-current@freebsd.org> Subject: Re: [RFC] Un-staticise the toolchain Message-ID: <20120501135530.GA50127@in-addr.com> In-Reply-To: <AF37B4BF-69D5-41D3-819A-0252911CBC89@cederstrand.dk> References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <20120426134140.GF14350@lo0.su> <CADLo838sdUT2e%2B7j8vCyOmDithLsh3kwDd_z04dWaPoiMphPDQ@mail.gmail.com> <4F99ACF9.2050609@infracaninophile.co.uk> <CADLo83_sr=13H=9nnrdge0jJaOh5Bk2N_gg=Gf-uYhwM8jm7Xg@mail.gmail.com> <42D8809D-0E99-47A5-802F-71991B5B0B8D@cederstrand.dk> <A79EE48D-A2AC-4D35-B156-1F58D17F77DD@kientzle.com> <AF37B4BF-69D5-41D3-819A-0252911CBC89@cederstrand.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 01, 2012 at 01:53:58PM +0200, Erik Cederstrand wrote: > Den 01/05/2012 kl. 07.52 skrev Tim Kientzle: > > > > On Apr 30, 2012, at 6:41 AM, Erik Cederstrand wrote: > >> > >> Can anyone explain to me why the dynamically linked version is significantly slower? What are the extra steps involved compared to a statically linked binary? > > > > At the risk of dramatically over-simplifying?. > > > > When a static binary is started by the kernel, it does the following: > > * Initializes some libc internals. > > * Calls main. > > > > When a dynamic binary is started by the kernel, it does the following: > > * Initializes some libc internals. > > * For every dynamic library referenced by this executable: > > - loads the dynamic library into memory > > - fixes up references > > * Calls main > > > > The process of loading the required libraries and fixing up references > > can be quite time-consuming. > > Thanks for the explanation. In the previous 'make index' benchmark by > Chris, make is called very often, which means the dynamic libraries > should already be loaded into memory after the first run, right? Which > means the extra time is being spent fixing up references? To an extent, yes. However the kernel still has to do some work to resolve the filename for the library to an inode, check to see if that inode is already loaded into memory, and then map the pages for the shared libraries into the new process that is requesting them. I may be misremembering (it is many many years since I had anything to do with the VM system) but I think some of that effort is non-trivial. If you want a high-level view of what goes on run ldd `which ls` check that it has libraries to load and doesn't say "not a dynamic ELF executable", and then run: ktrace ls kdump | more All the system calls related to resolving and loading shared libraries take time. I realise "ls" is not "make", but it should give you an idea. Gary
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120501135530.GA50127>