[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[not about] gc-by-area and host uptimes
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,
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.
mainly to the reliability of the Symbolics hardware and software, we are
rarely forced to do so unexpectedly except due to our own foibles.