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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> The difference is that when an idle timer runs a long uninterruptible
> calculation, the user thinks Emacs is idle, so having a character
> appear, or Emacs respond to a command with a prompt, after a
> significant delay makes a very bad UX.  By contrast, when a command is
> running, the user will normally know that Emacs isn't idle, so a
> delayed response will be less of a surprise.

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.  In the
idle-GC the time should be arguably a bit *shorter* because only N% of
the GC is counted towards to total delay before sending the response.

>> > Also, we already try running GC each time Emacs becomes idle.
>> Do we?  I thought so as well, but I couldn't see any evidence of it in
>> the code.
> It's in keyboard.c, right after we auto-save when enough idle time has
> passed:
>
>       /* 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.

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.


        Stefan