Extra systems in world load

["David L. Andre" <DLA%jasper.scrc.symbolics.com@RELAY.CS.NET>]

    Date: Tue, 31 Oct 89 23:05:32 EST
    From: barmar@Think.COM

       From: rshu@ads.com (Richard Shu)
       Date: 1 Nov 89 01:32:14 GMT

       I can think of a couple of cases where doing this would increase
       response time for a developer.  These are:

       1) Doing package DWIM
       2) Doing List Callers

       In both these cases, the presence of a package with many symbols
       will probably cause a significantly longer response time.  I don't
       know a lot about how symbols are implemented but I assume there
       is a separate hash-table for each package and that the above
       functionalities involve paging the hash-table for each package.

    You are correct about package DWIM, but I think the effect would be minor.
    Looking up a symbol in a package generally only requires about two page
    faults: one for the hash table header, and another for the page containing
    the array element indexed by the hash function.  My Lispm currently has
    about 100 packages, so every additional package would slow down package
    DWIM by a percent, which isn't significant in my book.

    I don't think it should slow down List Callers at all.  Ever since Genera
    7.0, List Callers has worked by using a table keyed off the symbol or
    function name.  The only time the extra systems would slow things down is
    when the who-calls database is being built from scratch, which would
    probably be before saving the band.

By the way, Package DWIM has been reimplemented to be much faster in
8.0; adding packages or adding symbols to existing packages doesn't slow
it down nearly as much as it used to.

List Callers may be faster in Genera 8.0, depending on schedule and
quality constraints.  However, in exchange for a much more compact and
accurate database, its performance would no longer be a constant as it
is in the present; its time would be roughly proportional to the number
of callers of a function (not the total number of functions).  Anyway,
stay tuned on this one.

       BTW, I've wondered for several years if one could effectively "unload"
       software by doing a remob on all the symbols in a package.
       If the number of symbols is large and many of them are functions,
       would there be a significant recovery of free space?

    In fact, all you really need to do is SI:PKG-KILL the package.

    The problem with this, however, is that functions are normally allocated in
    a static area, so they'll get saved even though they aren't referenced.
    Maybe Optimize World cleans this up.

And functions reference the symbols which name them, so the symbols
themselves won't be reclaimed.  And the symbols' property lists
reference the previous definitions of the functions, so they couldn't be
reclaimed...  ad nauseum.

In fact, there is no documented way to GC compiled functions and symbols
which works.  The problem is that you have to prune unimportant
references to symbols and compiled functions before running a GC, and
then reassemble the remaining references after GC completes.  (This is
in fact what Symbolics does with worlds before releasing them.)

The problem is in fact worse when you start to take into account Flavors
and CLOS data structures, as well as arbitrary data structures created
by the programs themselves.

So it can be done, but for customers who don't have overconfigured
world-building machines which can run for days doing the job, it's
easier to just reboot and cleanly load the software.