Date: Tue, 23 Jan 96 10:50:52 MET From: Greg Lehey <lehey.pad@sni.de> To: curt@emergent.com (Curt Mayer) Subject: Re: stanford benchmark/usenix Message-ID: <199601230956.KAA18725@nixpbe.pdb.sni.de> In-Reply-To: <199601221935.LAA19317@bluewhale.emergent.com>; from "Curt Mayer" at Jan 22, 96 11:35 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > I had thought of a part of the system startup that checks the > > processor type and puts in the correct hard links (symlinks are slower) > > before any program gets started. It would probably be a good idea to have > > an emergency program which reinstated the generic libraries, too. > > Greg > > just a nit. symlinks are not that much slower, since the 4.4 source base > there has been no i/o associated with a symlink. > > stat-ing file > Mon Jan 22 11:28:50 PST 1996 > Mon Jan 22 11:28:56 PST 1996 > stat-ing link > Mon Jan 22 11:28:56 PST 1996 > Mon Jan 22 11:29:04 PST 1996 > > in between timestamps are 50000 calls to stat. as you can see, the incremental > cost of hardlinks to symlinks is about 30%. another way of looking at it is > that stat-ing a link takes about 120 microseconds, and stat-ing a symlink > takes about 160 microseconds on a 486 dx2-80. hardly time for a disk i/o, > or even a cache reference. How many different links did you access? OK, I can see that there's a good chance of the links to the libraries being cached, but whichever way you look at it, a symlink is still slower. What's the advantage? Oops, here comes another religious war... Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601230956.KAA18725>