Path: utzoo!utgpu!watserv1!watmath!att!linac!uwm.edu!cs.utexas.edu!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.bugs.4bsd
Subject: Re: Complexity of reallocating storage (was users command crap)
Message-ID: <4701@goanna.cs.rmit.oz.au>
Date: 4 Feb 91 04:52:47 GMT
References: <15325:Jan2903:19:4991@kramden.acf.nyu.edu> <21548@yunexus.YorkU.CA> <2886@charon.cwi.nl>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 19

In article <2886@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes:
> Ah, but that is the problem.  Just as fast comes in flavors.  You have CPU
> time, real time, IO time and some more.  If one of the programs uses more
> passes it is not equally fast IO time wise ...

I am firmly in the "read it once" camp, but it's worth pointing out that
operating system features can invalidate some obvious conclusions.  One of
the things that I have found tricky is benchmarking programs that read
files under UNIX; the disc block cache means that the second time a program
reads a file much of it is still there in memory.  In the case of a program
reading /etc/utmp (often rather small) twice in rapid succession, the
second read stands a good chance of finding the file still in memory.  On
another operating system, or with different loads, things might be different.
Provided a program is *documented* as relying for its efficiency on such
operating system features, I think that's fair enough.

-- 
The Marxists have merely _interpreted_ Marxism in various ways;
the point, however, is to _change_ it.		-- R. Hochhuth.