LispMachine File Reading Time

[Keith Price <price%iris.usc.edu@USC.EDU>]

From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: LispMachine File Reading Time.

    Did you use :ELEMENT-TYPE 'STRING-CHAR streams?  If not,
    you were in some sense comparing apples and oranges, and the
    real Symbolics times will be noticably faster.
The manual claims that that is the Symbolics default.

    It is  very important when reporting benchmarks to report
    all relevant issues like this.

I only claimed that I was using the local system (system designer) defaults - 
designers are responsible for doing things right, if they don't they deserve 
comments. 

      Date: Thu, 18 Jan 1990 8:37:02 PST
      From: Keith Price <price%iris.usc.edu@usc.edu>
      90%+ of the time goes to the (read).  

    Meaning?  I would guess that by this you mean that 90% of the time was spent
    inside READ exclusive of time spent inside READ-CHAR or :TYI.  Is this what
    you meant?

I thought it was obvious, (read) is what the user sees, that is where the 
time goes, not processing the results of the read.

   If you're going to report times including Paging time on a Symbolics machine,
   you had better compare memory sizes and disk organization.  Is the Symbolics
   machine doing paging and file I/O from the same disk drive?  Is the LMFS
   scattered around in several FEP files on one drive?  Is it fragmented?  What
   kind of disk(s)?

Paging times were included to eliminate this from being a serious problem.  The
word included means the times are in the total, and are given separately.

    Did you include file opening & closing time, or just file processing time?

Open/Closing time is not relevant when the total is > 10 seconds.  The time is 
the entire operation, open, read, process, close.

   I don't mean to imply that your benchmark isn't useful, but it would be a lot
   more useful if you were more careful about reporting your test conditions.
   Too often, people do good benchmarking and then spoil it by reporting piecemeal
   results.
The test was default configurations, i.e. what the system designer thinks is 
important.  This may be more important than what is possible.  Note that my 
main concern was that the relatively poor performance on input when compared
to all other operations.  Even with the VAX8600 speed, it was slower on the
other large tests and the Sun-4 was often slower than the Sun-3.
	Keith Price.
	price@usc.edu