From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from adsl-216-102-199-169.dsl.snfc21.pacbell.net ([216.102.199.169]) by hawkwind.utcs.utoronto.ca with SMTP id <25527>; Wed, 12 Jan 2000 16:14:53 -0500 Received: (from haahr@localhost) by adsl-216-102-199-169.dsl.snfc21.pacbell.net (8.8.7/8.8.7) id QAA07822; Sat, 8 Jan 2000 16:22:08 -0800 X-Authentication-Warning: iadd.jivetech.com: haahr set sender to haahr@jivetech.com using -f From: Paul Haahr X-Attribution: haahr Message-Id: Date: Fri, 31 Dec 1999 19:22:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Tim Goodwin Cc: rc@hawkwind.utcs.toronto.edu Subject: Re: Dynamically loading readline on demand (was Re: rc futures) In-Reply-To: References: <199912151632.LAA19961@smtp3.fas.harvard.edu> X-Mailer: VM 6.30 under Emacs 20.3.1 Tim Goodwin wrote > I took an rc script that does nothing (makes no system calls) except > fork() and wait() 10000 times. Are you sure it doesn't exec at all? Most of the costs associated with dynamic loading would correspond with execs. My comments below work on the assumption that an exec of rc is included in your timing tests. If it wasn't, I'd be curious to see your script. > Here are the results I got on my 200MHz Linux PC (us = microseconds). > > rc.static 744us > rc.rl.static 865us > rc.dynamic 1071us > rc.rl.dynamic 1442us I guess it depends on what your test measures. A ~30% performance penaly doesn't seem like that much if it's saving enough by sharing the library with other clients. > ([...] Why does dynamic linking increase the user time? I have no > idea, but it reliably does on both these platforms.) (If you really care, see John Levine's excellent _Linkers and Loaders_ book, especially chapters 9 and 10. Available at http://www.amazon.com/exec/obidos/ASIN/1558604960/paulhaahrA and finer tech bookstores. The short answer is ``because dynamic linking is done with user-space code.'') > My conclusion from this is that using readline is an insignificant > (although measurable) performance hit. But dynamic linking is always > a bad idea. No. Dynamic linking slows startup time down with the gain of using less memory overall. It also makes systems more flexible, allowing the upgrade of library code without explicit relinking of applications, which is a big win. > I therefore intend to drop my suggestion that rc should itself load > readline on demand, and instead to make the following minor changes > for rc-1.6b3. > > 1. Modify the INSTALL documentation; we should always recommend linking > statically. > > 2. Modify configure.in, so that, if we are using gcc, `-static' is > specified. I disagree. Overall system resource consumption still goes down with dynamic linking and loading. If a system is set up to use dynamic linking by default, why should rc override that? A number of us argued squarely against dynamic linking in the early '90s, at least partially because dynamic linking encouraged software bloat. The bloatists won because techniques like dynamic linking (along with Moore's law) made the costs of bloat minimal. (And, when it comes down to it, bloat in libraries is probably a good thing.) --p