Re: [Gcl-devel] efficiency of package symbol tables

[Bruno Haible]

Camm Maguire wrote:
> The
> problem is that our current implementation of (intern (write-to-string
> ...)) generates 3 temporary strings and churns the GC unnecessarily.

That's not really the problem, because it's quite typical for Lisp programs
to allocate one kind of object for temporary use and another kind of
object for permanent storage in a growing heap.

If you optimize write-to-string now, you just make this particular bench-
mark work better, but you don't solve the problem.

> The way it works now, the maximum number of pages for each
> type will be increased when the free area is less than 30% of the
> total available after GC.  This is user settable via the function
> si::allocate-growth.  The info page has a good description.  Also
> settable with this function are the minimum and maximum pages in the
> increment, and the percentage by which the space should be expanded
> when the minimum and maximum are not hit.

I see, thanks. The problem appears to be that the different types
of pages have an independent max-growth-until-GC limit.

The problem we see is that the number of the STRING pages stays at 32,
since all the string allocations are temporary. However there is no
such thing as a "GC for STRING" - the GC scans all the heap, including
the growing number of SYMBOL pages. It's only a "GC triggered by STRING".
Since the cost of the GC is approximately equal to the *total* number of
pages in use (ok, you can probably declare that a STRING page and a
BIGNUM page are less costly than a CONS page or a VECTOR page since
they don't contain pointers), any max-growth-until-GC limit that
ignores the *total* number of pages will have the problem.

> Perhaps you have a suggestion?

My suggestion would be that the default max-growth-until-GC limit
of each type of page be a percentage of the *total* number of pages
in use.

Bruno