- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 20 Dec 94 11:30:24 PST
- To: David - Morris <dwm@shell.portal.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> A little experiment should help shed some light on this. On a reasonably
> fast machine (a DEC3000/600), I did (after first arranging for /vmunix
> to be in the filesystem cache):
> % time wc /vmunix
> 15102 97927 6351808 /vmunix
> 0.93u 0.14s 0:01 94% 0+1k 0+0io 15pf+0w
> a% time ngrep masinter@parc.xerox.com /vmunix
> 0.27u 0.19s 0:00 74% 0+1k 4+3io 47pf+0w
> %
> ngrep uses a modified Boyer-Moore algorithm. Larry is right;
I'm sorry but I'm quite skeptical about your experimental design and
it's applicability to the HTTP context as well. For starters finding
split points in an inbound byte stream is a different problem than
presented by a file full of bytes all present and waiting for processing.
Well, I tried the same experiment, except with ngrep getting its
data from a pipe:
% cat /vmunix | /bin/time ngrep masinter@parc.xerox.com
real 0.6
user 0.3
sys 0.1
%
I used /bin/time because the csh built-in "time" command won't
accept piped input. So, within the resolution of /bin/time's
measurement, the user-mode time is the same. The extra 0.2 seconds
of "real" time may come from having to share the CPU with the
cat command, which takes about that long when copying the file
to /dev/null.
Secondly, I am suspicious that there is a marked difference in the quality
of implementation of wc vs. ngrep interms of program organization.
Well, you caught me there. Wc is pretty darned slow; after all,
"cat /vmunix >/dev/null" takes 0.0 seconds of user-mode CPU time.
But that's largely irrelevant to Larry's argument; the absolute
cost of the Boyer-Moore string search is still too small to worry
about.
-Jeff
Received on Tuesday, 20 December 1994 11:44:33 UTC