[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LISPM I/O performance

  From: "kosma%ALAN.kahuna.decnet.lockheed.com %ALAN.kahuna.DECNET.LOCKHEED.COM"@warbucks.ai.sri.com
  Date: Fri, 26 Jan 90 13:51:32 CST
  To: slug@warbucks.ai.sri.com
  Subject: Re: LISPM I/O performance
  Received: from BLAISE.kahuna.decnet.lockheed.com by ALAN.kahuna.decnet.lockheed.com via INTERNET with SMTP id 18447; 26 Jan 90 11:49:29 PST
  Date: Fri, 26 Jan 90 11:49 PST
  From: Montgomery Kosma <kosma@ALAN.kahuna.decnet.lockheed.com>
  Subject: Re: LISPM I/O performance
  To: slug@ALAN.kahuna.decnet.lockheed.com
  In-Reply-To: <9001260601.AA09618@uunet.uu.net>
  Message-ID: <19900126194917.2.KOSMA@BLAISE.kahuna.decnet.lockheed.com>
  ---> Show Directory (files [default BLAISE:>*.*.newest]) BLAISE:>*.*.newest
    1796 free, 11924/13720 used (86%, 3 partitions) (LMFS records, 1 = 4544. 8-bit bytes)
        bigfoo.foo.1   105 471290(8)     !   01/26/90 11:38:17 (01/26/90)   Kosma
        File-Server.directory.1    1   DIRECTORY !   12/05/89 13:29:36 X=12/05/89 LISPM
        kosma.directory.1    1   DIRECTORY !   04/07/89 16:29:36 X=01/18/90 LISPM
        laszlo.directory.1    1   DIRECTORY !   11/22/89 19:45:35 X=12/04/89 Laszlo
  108 blocks in 4 files
  ---> (si:without-interrupts (scl:time (zwei:find-file#P"BLAISE:>bigfoo.foo.newest")))
  Evaluation of (ZWEI:FIND-FILE #P"BLAISE:>bigfoo.foo.newest") took 22.021669 seconds of elapsed time including:
    2.250 seconds processing sequence breaks,
    3.997 seconds in the storage system (including 1.379 seconds waiting for pages):
      1.727 seconds processing 530 page faults including 23 fetches,
      1.935 seconds in creating and destroying pages, and
      0.334 seconds in miscellaneous storage system tasks.
  16,303 list, 930 structure words consed in WORKING-STORAGE-AREA.
  55 list words consed in *HANDLER-DYNAMIC-AREA*.
  18 list, 377 structure words consed in *PRESENTATION-AREA*.
  366 list, 205,378 structure words consed in EDITOR-LINE-AREA.
  43 list, 32 structure words consed in *ZMACS-BUFFER-AREA*.
  #<ZWEI:FILE-BUFFER "bigfoo.foo > BLAISE:" 41201260>
  not much improvement.  Still far too slow for me.  This is with a *local* file, 
OK, i didn't expect much improvement, but using without-interrupts is the
fairest way to compare LISPM times to UNIX times.

I'm beginning to suspect that there is consing going on when reading a
buffer, at least i know this is true with NFS streams.  If we could
reduce this, and write stream mixins that inline some of the (SEND
SELF ..)  we should be able to get some improvements.

        This works out to around 14K bytes/second, an abominable transfer rate,
        if you don't factor in overhead.  I don't know what zwei:com-read-file
        is doing internally, and I don't really care--it doesn't really matter.
        What DOES matter is that reading this file into ZMACS takes 16 to 17
        seconds, while reading the same file into emacs on my amiga takes 1 to 2
        seconds, and on our sparcstation loading it into gmacs, it's basically
        instantaneous (even I was surprized).
      I think it would be fairer to try ftp-find-file in Gnu EMACS.
  why?  and by the way, I know it's not "really" a transfer rate, but nonetheless IT IS THE
  RATE THAT THE USER SEES!  (that was in repsonse to another message which I don't have handy).
Sorry, i forgot that you were doing local IO.

      I've suddenly found my self having to read in several larges files
      prepeatedly.  For example:
      -rw-rw-rw-  1 kanderso  5735077 Jan 23 00:57 rt.det.shrink
      My first version used READ.  My second version used SI:XR-READ-THING
      and internal read function.  This took 55 minutes to read in
      [:element-type 'string-char] .  I then wrote my own version of
      parse-integer [because the standard one conses when building
      double-floats and bignums], and functions to parse floats and symbols.
      Using these took 42 minutes about 30% less.
  Too bad it couldn't get under *5* minutes :-/.