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