Babyl files, slow as molasses

["J. Scott Penberthy" <JSP@ibm.com>]

1    Date: Fri, 6 Nov 87 07:13 EST
    From: Jeffrey Mark Siskind <Qobi@ZERMATT.LCS.MIT.EDU>

    [GC discussion of process tags..]

    ...  Often, I run many tasks at once, such
    as reading my Babyl file in Zmail (my Babyl file
    is over 4 megabytes long and takes an hour to read),

0It seems that what you were asking in your letter (i.e. that Symbolics
revamp their existing GC and memory management routines), may be too
general a solution to the slow lispm problem.  Perhaps a quicker
solution would call for a better management of babyl files, since the
mailer *always* seems to take such a long time to parse and/or update
its mail files.  And, as we all have seen, a bogged-down mailer greatly
decreases LISPM performance.

As it exists, the Symbolics mailer reads in all messages within each
mail file.  If a mail file isn't in KBIN format, the mailer also must
re-parse all that file's messages.  A better approach would use
"virtual" messages.  In this case, the mailer would only have to read in
a header from each mail file; this header would contain the pre-parsed
summary line info for each message, plus a pointer to either some
location in the mail file or to some other external file.  Only when a
user requested to see a message would the mailer have to actually read
in the entire message body.  The document examiner, for which Symbolics
once won an award, maintains this "virtual copy" method for all
documentation.  Why not use it for mail files?  Imagine the
ramifications --> it would take only a few seconds to load a mail file
with hundreds of messages, not an hour.


Cheers,
Scott