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