LISPM I/O performance

["John R. Dunning" <jrd@STONY-BROOK.SCRC.SYMBOLICS.COM>]

    Date: Thu, 18 Jan 90 10:21 EST
    From: RWK@FUJI.ILA.Dialnet.Symbolics.COM (Robert W. Kerns)
[...]
    The amount of overhead involved depends greatly on what kind of
    file access you were using.  It's been a long time since I've
    done any systematic measurements, but I would expect to see ratios
    of 30% - 300%, depending on exactly what kind of connections you're
    working with.

Right.  I *have* done some systematic measurement of Lispm I/O recently,
and you really do see pretty dramatic differences based on what kind of
file you're reading, how you're reading it, and things like the state of
the network, application paging etc.  

One of the easiest ways to lose performance is to do lots of
byte-at-a-time operations when you could have just as easily read lines
or whole buffers-full or whatever.  For 8.0, we've changed around the
character stream stuff to be buffered (rather than the unbuffered
approach used in 7.x); that one change reduces character-stream overhead
by a factor of about 3-4.

[Danger! Symbolics employee making performance claims! :-]

Please note that this doesn't mean any application that reads files will
be 4x faster; simply that the overhead attributable to character streams
is reduced.  As RWK and others have pointed out, that's often not the
place where you're really spending your time.  The point is, that you
can sometimes win big by making a few strategic mods to the way you do
your I/O.

I guess the other point is that we really do care about things like I/O
performance, and sometimes we have a chance to do something about it.