emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: Re: Garbage collector: is 800kb a good default?
Date: Thu, 09 Apr 2020 14:42:56 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>> What you're pointing out is that from the user's point of view, a GC
>> during idle time is free (so it can occur frequently) and also that
>> a GC during non-idle time can delay redisplay, so (ignoring all
>> other impacts of GC) we should refrain from running GC while
>> non-idle and trigger GC everything we're idle.
> Let's not forget that running GC while Emacs is idle will make Emacs
> less responsive if the user starts typing while GC is in progress,

The argument for GC-when-idle goes that if this happens it's not really
worse than what we have now, because if the GC hadn't started "before
the user starts typing", it would have run as part of the command
launched by the user, so from the user's point of view there's no
noticeable difference.

> specially if gc-cons-threshold is high.  So it isn't entirely "free".

In my sample patch I set the "idle GC threshold" to half of the normal
threshold, which means that we'll GC about twice as often.  In such
a case, as long as the probability that the "user starts typing" in the
middle of a GC is less than 50%, the user's commands will not be delayed
by GC more often than with the current strategy.

The actual probability that the user starts typing in the middle of an
idle GC depends on how much idle we wait before starting the GC, how
much a GC takes, and the distribution of time between user events.
But it should be pretty easy to keep it below 50%.

> 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.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]