W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: MIME and binary transport

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 20 Dec 94 11:30:24 PST
Message-Id: <9412201930.AA23280@acetes.pa.dec.com>
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

Received on Tuesday, 20 December 1994 11:44:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:10 UTC