Re: Garbage collector: is 800kb a good default?

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Thu, 09 Apr 2020 15:31:43 -0400
> 
> No, that's not what I was saying.  What I was saying is that in the"idle
> GC case" the events are as follows:
> 
> 1- 100%-N% of the GC runs while idle.
> 2- the user hits a key
> 3- the remaining N% of the GC runs.
> 4- the command runs
> 
> whereas in the non-idle GC what happens is:
> 
> 1- the user hits a key
> 2- the command starts
> 3- the GC gets run
> 4- the command continues and finiches
> 
> To the user, the result is pretty much the same: in both cases Emacs
> took "time to run the command + time to GC" before responding.

We are miscommunicating.  My complaint was about the _response_ time,
which is the time that passes between me pressing a key and Emacs
reacting to that.  In your description above it is the time between
"the user hits a key" and "the command starts".  That GC happens
during the time the command runs is less annoying, because the user
sees a responsive Emacs.

You can try it yourself: set up an idle timer that would call a
long-running function, then try typing something while it runs.

> >       /* If there is still no input available, ask for GC.  */
> >       if (!detect_input_pending_run_timers (0))
> >     maybe_gc ();
> 
> But that's not the same: this "maybe_gc" rarely triggers because it uses
> the same thresholds as normal code evaluation, so if the GC was not
> triggered while running the last command it usually won't trigger
> here either.

We have no guarantee that GC has an opportunity to run every command,
do we?  It very much depends on what that command did.  Thus, this
call is not really a no-op.

> The fundamental idea of idle-GC is to use a *lower* threshold while
> idle, so as to increase the probability that the GC happens on that
> occasion rather than one of the other "maybe_gc" checks.

We can easily do that, I think.  Most of the code is already there.