Complexity of reallocating storage (was users command crap)

Richard A. O'Keefe ok at goanna.cs.rmit.oz.au
Mon Feb 4 15:52:47 AEST 1991


In article <2886 at charon.cwi.nl>, dik at 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.



More information about the Comp.bugs.4bsd.ucb-fixes mailing list