> 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