Re: garbage collection slowdown

[Mikael Djurfeldt]

Den ons 5 feb. 2020 23:32Han-Wen Nienhuys <address@hidden> skrev:

On Wed, Feb 5, 2020 at 5:23 PM Ludovic Courtès <address@hidden> 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 - address@hidden - http://www.xs4all.nl/~hanwen