[not about] gc-by-area and host uptimes

[Kalman Reti <Reti@SCRC-STONY-BROOK.ARPA>]

    Date: Thu, 16 Feb 89 12:04 CST
    From: William D. Gooch <ai.gooch@MCC.COM>

	     There are many parts of our software that are less efficient than we'd
	     like, but there are only so many man-hours available to improve things
	     and hundreds of times more work than we can possibly ever get to.

	     One such program is the loader; we try to optimize the things with
	     the highest payoff, and the loader hasn't seemed to fit in this
	     category.  Is it really more important for you that Symbolics work on
	     making loading fast, as opposed to say, function calling, message sending,
	     garbage collection?

    Not "as opposed to" but "in addition to."  
Would that we had the resource to do everything at once, but we unfortunately
we have to pick and choose.  Even though we know about it, we haven't chosen
loading, because it happens relatively infrequently compared to everything else.

However, file I/O in general is one of those things that happen all the time,
and I agree with you that it should be high on the priority list.  Unfortunately
the slowness of loading/dumping has nothing to do with the file I/O 1per se0, but with
the converting and unconverting of data from an external to an internal representation.
					       Although I completely agree
    with almost all of what you have said, I must point out that file I/O is
    one of the slowest parts of the Symbolics system, and this is presently
    a significant performance problem for my group.  We load up a big set of
    large binary-format knowledge base files, and it takes long enough to
    make most of us very reluctant to reboot unless we're forced to.  
Information like this is valuable to us in planning where we put our effort.
If the perception of our user base is that loading is one of the highest
priority areas that need improvement, we will certainly try to respond.

However, it isn't immediately obvious to me why you can't load the knowledge base
files into a world once and then disk-save an IDS world that your people just
boot (or netboot) subsequently, until enough changes to the knowledge base accumulate
to warrant doing it again.  This is the strategy we follow here, and again, if there
is some reason it won't work in your case, you should let us know.
								      Thanks
    mainly to the reliability of the Symbolics hardware and software, we are
    rarely forced to do so unexpectedly except due to our own foibles.