Re: garbage collection slowdown

[Mikael Djurfeldt <mikael@djurfeldt.com>]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

Den ons 5 feb. 2020 23:32Han-Wen Nienhuys <hanwenn@gmail.com> skrev:

>
>
> On Wed, Feb 5, 2020 at 5:23 PM Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Weird.  It would be interesting to see where the slowdown comes from.
>> Overall, my recollection of the 1.8 to 2.0 transition (where we
>> introduced libgc) is that GC was a bit faster, definitely not slower.
>>
>> That said, does LilyPond happen to use lots of bignums and/or lots of
>> finalizers?  Finalizers, including those on bignums, end up being very
>> GC-intensive, as discussed in my recent message.  Perhaps that’s what’s
>> happening here, for instance if you create lots of SMOBs with a free
>> function.
>>
>
> No, I think it's because in some phases of the program, there is a lot of
> heap growth, with little garbage generation. This causes frequent
> (expensive) GCs that don't reclaim anything.
>

When programming dynamic vectors, it is common to adapt the size of newly
allocated chunks by letting them grow in proportion to vector size.

Could the frequency of GC be adapted similarly such that the balance
between GC and allocation is shifted towards allocation in phases with a
lot of heap growth?

More concretely, this could either be achieved by letting the newly
allocated chunks grow in proportion to allocated memory (as I think it was
in the 1.8 GC---don't know about now) or by choosing to not do a GC every
time, but instead directly allocate if running average of GC gain is small
compared to allocated memory.

Of course these are issues at research level...


>
> --
> Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen
>

[-- Attachment #2: Type: text/html, Size: 3110 bytes --]