Re: [PATCH v2 3/3] Start opportunistic GC timer at startup

[Stefan Monnier]

>> Maybe what I want to compare it against is the number of commands
>> during which the GC is run exactly once?  The idea is to filter out
>> those commands which are compute-intensive and hence run the GC
>> internally (for which an opportunistic GC is of no use anyway).
>
> What do you mean by "during which"?
> Is the time used by redisplay after a command included or isn't it?

I wish it were, but the measurement method I'm using (via
post-command-hook) doesn't do that, sadly.

> My point is that commands are separate from redisplay in Emacs, and
> there's a lot of GC that's unfortunately goes on as part of, or
> immediately after, a redisplay cycle in latest versions of Emacs.

Indeed (tho I don't understand why you say "or immediately after").

>> So I added:
>> 
>>     (defvar gc--opportunistic-single-gc-cmds 0)
>>     (let ((last-gcs nil))
>>       (add-hook 'pre-command-hook (lambda () (setq last-gcs gcs-done)))
>>       (add-hook 'post-command-hook
>>                 (lambda ()
>>                   (if (eq (1- gcs-done) last-gcs)
>>                       (setq gc--opportunistic-single-gc-cmds
>>                             (1+ gc--opportunistic-single-gc-cmds))))))
>> 
>> So far, this seems to indicate that it's working:
>> OT1H `gc--opportunistic-single-gc-cmds` stays much lower than
>> `gc--opportunistic-counter`, indicating that we seem to be able to avoid
>> GC in many cases, and OTOH `gc--opportunistic-counter` is much lower
>> than `gcs-done` indicating that we're not excessively increasing the
>> number of GCS.
>
> What is the effect on the memory footprint?

Haven't noticed any impact (and I don't expect it to have much impact
since, contrary to Andrea's ELisp package, I don't touch the normal
thresholds, so the GCs can only be more frequent).


        Stefan