Re: Opportunistic GC

[Stefan Monnier]

A bit more than a year ago I wrote:
> So, while these numbers don't look completely hopeless, they seem to
> indicate that opportunistic GCs aren't very useful at least with the
> tuning parameters I used.  To be more useful, maybe we'd need to
> increase the non-opportunistic `gc-cons-percentage` and/or reduce the
> idle-time before opportunistic GC (see "magic formula" below).

I've recently been playing with tweaks to that code, basically setting
`gc-cons-percentage` to 0.5 and then calling
(garbage-collect-maybe 10) from the timer.

IOW multiplying by about 5 the amount of memory we can allocate within
a command before we call the GC, but in return running an opportunistic GC as 
soon as there's more than about half as much allocation as the normal threshold 
(0.5 during the command and 0.05 for the opportunistic threshold compared to 
0.1 all the time in the default settings).

The results are a lot more promising:

    ((jit 3 0 0) (cmd 7 3 8) (noncmd 23 3 10)
     (earlier-gcs . 79)
     (commands . 46027)
     (opportunistic-gcs . 576))

IOW, the vast majority of GCs are now opportunistic and very few commands
or jit-locks spent any time in the GC (I suspect most of the `noncmd`
GCs happened during auto-revert).

The higher `gc-cons-percentage` during commands should tend to increase
fragmentation a bit in the long run, but the lower `gc-cons-percentage`
used for the opportunistic GCs should have the opposite effect, so I'd
expect the overall long term health of the heap to be fairly similar.


        Stefan