[Top][All Lists]

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

Re: garbage collection slowdown

From: Mikael Djurfeldt
Subject: Re: garbage collection slowdown
Date: Thu, 6 Feb 2020 15:06:14 +0100

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

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 -

reply via email to

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