Re: Eager garbage collection

[Stefan Monnier]

> Setting a lower threshold there also prevents functions that may be
> executed by timers to leave the heap with garbage just before the user
> start the next command.

This is risky, tho, because a low threshold will increase the proportion
of time spent in GC, which could negatively impact the performance of
process-filters.

I do think it is good to move as much of the code to Elisp.  But the
patch Spencer sent only has 2 small parts in C: the gc-time tracker and
the gc-maybe function.

We could move the gc-time tracker to Elisp (and it could be a good idea
to do so, since I can imagine getting fancier in there.  E.g. instead of
tracking the actual GC time, we could track the "time relative to heap
size" which might allow us to better predict the time taken by the next
GC), but we'd still need some changes to the C code for example so that
`post-gc-hook` gets access to the elapsed time of the last GC.

For gc-maybe, we could arguably code it all in Elisp, indeed, as:

    (defun gc-maybe (factor)
      (let ((gc-cons-threshold (/ gc-cons-threshold factor))
            (gc-cons-percentage (/ gc-cons-percentage factor)))
        (eval (+ 1 1)))) ;; This internally calls the `maybe_gc` C function.

The `eval` part is quite hackish, tho, and the workings depend on
exactly when those gc-cons-* settings take effect which is not
documented either.

In contrast the C version is clear and direct, so I think I'm pretty
happy with the C version.


        Stefan