From owner-freebsd-current@FreeBSD.ORG Tue May 1 13:56:04 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48AFB106564A for ; Tue, 1 May 2012 13:56:04 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8FE8FC14 for ; Tue, 1 May 2012 13:56:04 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SPDYA-000D3W-M2; Tue, 01 May 2012 09:55:30 -0400 Date: Tue, 1 May 2012 09:55:30 -0400 From: Gary Palmer To: Erik Cederstrand Message-ID: <20120501135530.GA50127@in-addr.com> References: <20120426093548.GR2358@deviant.kiev.zoral.com.ua> <20120426134140.GF14350@lo0.su> <4F99ACF9.2050609@infracaninophile.co.uk> <42D8809D-0E99-47A5-802F-71991B5B0B8D@cederstrand.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-current FreeBSD Subject: Re: [RFC] Un-staticise the toolchain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 13:56:04 -0000 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