Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!agate.berkeley.edu!cgd
From: cgd@erewhon.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.os.386bsd.misc
Subject: Re: Shared Library Status ?
Date: 7 Mar 94 15:56:35
Organization: Kernel Hackers 'r' Us
Lines: 27
Message-ID: <CGD.94Mar7155635@erewhon.CS.Berkeley.EDU>
References: <JKH.94Mar5233255@whisker.hubbard.ie> <hastyCM8Buv.26z@netcom.com>
<michaelv.762936864@ponderous.cc.iastate.edu>
<hastyCM9r6q.KFB@netcom.com> <2lgb5g$11gc@introl.introl.com>
NNTP-Posting-Host: erewhon.cs.berkeley.edu
In-reply-to: tim@introl.com's message of 7 Mar 1994 16:51:28 -0600
In article <2lgb5g$11gc@introl.introl.com> tim@introl.com (Tim Chase) writes:
=>From a 486DX2-66 with 16MB RAM running NetBSD-current (sources current
=>as of today):
=>
=> shared:
=> 443.320u 78.500s 9:35.63 90.6% 0+0k 3108+24884io 0pf+0w
=> static:
=> 428.440u 65.360s 9:04.80 90.6% 0+0k 3027+24887io 0pf+0w
"DAMN!" i didn't realize it made that little difference. cool. 8-)
(i'd actually not benchmarked them, nor even compared them...)
=>This makes me wonder if there wasn't some problem with the earlier
=>implementations of shared libs didn't have a performance problem that
=>was fixed. I don't remember any discussion, however, of such a problem
=>but it's certainly possible.
umm, it *could* be that the slow binaries were linked with an out-of-date
set of libs, or something... if there were any "RRS" warnings on linking,
the resulting binaries would be slower than otherwise...
cgd
--
chris g. demetriou cgd@cs.berkeley.edu
you can eat anything once.