From owner-freebsd-hackers Fri Aug 29 22:18:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA19467 for hackers-outgoing; Fri, 29 Aug 1997 22:18:13 -0700 (PDT) Received: from mailbox.uq.edu.au (zzshocki.slip.cc.uq.edu.au [130.102.221.173]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA19458 for ; Fri, 29 Aug 1997 22:18:08 -0700 (PDT) Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by mailbox.uq.edu.au (8.8.7/8.6.12) with ESMTP id PAA02145; Sat, 30 Aug 1997 15:23:20 +1000 (EST) Message-Id: <199708300523.PAA02145@mailbox.uq.edu.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@freebsd.org cc: andrew@zeta.org.au Subject: Re: shared libraries? In-reply-to: Your message of "Thu, 28 Aug 1997 16:38:48 +1000." <199708280638.QAA18886@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Aug 1997 15:23:19 +1000 From: Stephen Hocking Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Snippage re performance impact of shared libs] My own take on this is that I've seen less memeory consumption when using shared libs uon an SVR4 system (as measured by top, sar et al). With shared libs and the cache issue, clustering commonly used routines together has a positive performance impact (indeed, there whas a good paper put out by the SVR3 guys when they implemented the shared libc as how they had to re-order to reduce resident set size and so forth). I have a collection of references floating around for all this, including one paper by a guy called Jerry Breecher(sp?) in which he re-ordered modules in shared objects on Unix systems and a Data general system and saw reduced memory usage and pageout rates. It appeared that a re-ordering based on the simple ranking given by prof et al gave most of the benefits of schemes using fancy time-ordering techniques (what modules were most used at each phase within a program). I've been meaning to hack together a simple perl script to automate this process - perhaps I ought to bump up the priority of this a bit. It's not a new idea of course, look at the MIPS tools pixie and coord (which admittedly are more biased towards restructuring basic blocks for otimal cache line use). Stephen