emacs-devel
[Top][All Lists]
Advanced

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

Re: Larger GC thresholds for non-interactive Emacs


From: Lynn Winebarger
Subject: Re: Larger GC thresholds for non-interactive Emacs
Date: Wed, 22 Jun 2022 19:48:59 -0400

On Wed, Jun 22, 2022 at 7:26 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Was there?  I see:.  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38345#71
> but it's a little more than a couple of months ago.
> I'm pretty curious because if I accumulate a large buffer of trace output
> (running memory up to 100s of MB), killing the buffer doesn't seem to
> impact gc time substantially.

The GC does not really look at a buffer's content, so unless there is
a non-trivial amount of text-properties (e.g. because of font-lock and
such), the GC will take about the same amount of time handling a large
buffer as handling a tiny buffer.

Similarly, whether the malloc library returns the memory to the system
or not shouldn't affect GC times very much if at all.  What does affect
GC time is the amount of live data as well as the total amount of data
that's under the GC's control (i.e. live data, garbage that still needs
to be collected, as well as data that's free but that we haven't been
able to return to malloc (via `free`)).

That's why I found it so confusing - as though the gc was traversing malloc's
free list.  Even if the text were killed and saved in the kill ring, it would be a 
lisp string, so the GC shouldn't be traversing it. 

I'm not particularly eager to recreate the problem, as I spent (at least) as 
much time trying to understand edebug's behavior as the lisp macro I was 
debugging.

It's possible there's something special about the edebug trace buffer, or (I suspect
more likely) one of those packages I set up made "kill-buffer" bury them instead.  I
just remember being very frustrated that the gc time seemed to grow proportional to
the size of the trace buffer and not be improved by running garbage-collect after
killing that buffer.

Lynn
 

reply via email to

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