Re: gc-phobia

[Thomas Bushnell, BSG]

Michele Bini <address@hidden> writes:

> IMHO the interpreter should minimize such consing in order to reduce
> the garbage collector's activity (eventually to disable it in some
> applications like batch processing), since waking up the garbage
> collector frequently, expecially when the heap grows large, kills the
> responsiveness of interactive applications and the raw performance in
> non interactive programs (e.g, a ray tracer), that are not given a
> chance to garbage collect while waiting for input. 

As for interactive programs, it's certainly an issue.  And the
interpreter should minimize consing just because that's good
optimization technique.  Guile isn't that concerned at the moment with
interpretive efficiency; experience shows that for most applications
that won't be a serious problem.  (For example, emacs generally isn't
thought to suffer too much.)

However, you are more than welcome to work on improving the efficiency
of the interpreter by adding optimizations for such things!  There is
a considerable literature on how to optimize Scheme.

As for non-interactive programs, you're incorrect.  Extensive research
has shown that the cost of keeping track of memory usage yourself is
generally worse than garbage collection.

> Also, there seem to be no way even for C code to free a cons cell
> explicitly, when you are sure that it will no longer be referenced.
> (except maybe by playing around with the freelist, something still
> beyond my understanding).

It's actually better to wait for gc than try to keep track yourself.
Plus, the whole point of gc is to guarantee that memory references are
always good; if you go around freeing cons cells, then you are
breaking that promise.

Playing around with the free list is Strictly Forbidden.  Don't do it.

> Implementation-wise, some changes i'd propose are:
>  * to specialize the scm_call_* and scm_apply_* functions, which
> currently just build lists for the arguments and pass them to
> scm_apply.

This might be a reasonable optimization, but you haven't said enough
to say just what you have in mind.

>  * create C functions to free pairs and other boxed data explicitly,
> and eventually even create a scheme callable interface for them (this
> could be beneficial to number processing applications, when dealing
> with fixed matrices, complex or floating point numbers.

This is seriously misguided.  Bad enough to allow C to break the gc
abstraction, but advocating Scheme doing so?  No, that's just a
mistake on ten grounds.  It results in slower programs with more
bugs. 

>  * reimplement some function that apply a variable number of arguments
> to other functions, (like call-with-values, map, for-each), and
> specialize the case in which the closure to be called takes a fixed
> number of arguments.

Again, this is a reasonable optimization strategy.  (It's not
particularly related to GC.)  I'm sure work on this would be
appreciated.