From owner-freebsd-hackers Thu Aug 28 13:06:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18227 for hackers-outgoing; Thu, 28 Aug 1997 13:06:26 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18149 for ; Thu, 28 Aug 1997 13:05:55 -0700 (PDT) Received: from gurney.reilly.home (d26.syd2.zeta.org.au [203.26.11.26]) by godzilla.zeta.org.au (8.8.5/8.6.9) with ESMTP id GAA00245; Fri, 29 Aug 1997 06:03:22 +1000 Received: from gurney.reilly.home (localhost [127.0.0.1]) by gurney.reilly.home (8.8.5/8.8.5) with ESMTP id QAA18886; Thu, 28 Aug 1997 16:38:50 +1000 (EST) Message-Id: <199708280638.QAA18886@gurney.reilly.home> Date: Thu, 28 Aug 1997 16:38:48 +1000 (EST) From: Andrew Reilly Subject: Re: shared libraries? To: toor@dyson.iquest.net cc: perlsta@sunyit.edu, hackers@FreeBSD.ORG In-Reply-To: <199708280507.AAA07664@dyson.iquest.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 28 Aug, John S. Dyson wrote: > Believe it or not, shared libs often hurt more than help. Even with an > ideal scheme that is prelinked, a program can take MORE memory, not less. > We share the .text of programs even without using shared libs. In the > case of shells, shared libs are usually a loose. A rule of thumb that I use > is (These are only my opinions): [list elided] I remember a very strong and well argued argument along these lines with a (Japanese?) guy, either on usenet or one of the early BSD newsgroups, around the time that 386BSD first appeared (although I think that the context was BSD Unix on a MIPS box, perhaps the Sony 3xxx series, which never had shared libraries). His argument was that for programs that use a small collection of functions from large libraries (of which X applications are particular culprits?), the cost to real memory can be higher than it would be without shared libraries. One reason is that dynamic loading and shared text keeps the impact low, as John described above. Another problem that seems (more?) interesting is real-memory fragmentation (wastage?) incurred by unused functions that reside on the same pages in the library file as used functions, and so occupy memory when the used function is demand loaded. Has anyone considered building a shared library use-analysis tool, to attempt to optimise the ordering of objects within the various shared libraries, so that the "most used" core of modules were concatenated, probably at the front, with less commonly used functions falling to the tail, so they would mostly not be paged in? -- Andrew "The steady state of disks is full." -- Ken Thompson