On Tue, Feb 4, 2020 at 7:50 PM <jonas.hahnf...@gmail.com> wrote: > On 2020/02/02 22:33:50, hanwenn wrote: > > For testing, use > > > > https://github.com/hanwen/lilypond/tree/guile22-experiment > > So I ran this with the large example and I see > GC Warning: Failed to expand heap by 30635458560 bytes > a few times (that's 30 GB, my laptop only has 8 GB!!) and finally > warning: g_spawn_sync failed (0): gs: Failed to fork (Cannot allocate > memory) > Maybe exponential growth is not the best choice here? At least my system > can't handle this score anymore. > > Also most of the 'speedup' by this patch seems to come from segments > _after_ music interpretation (only 10% improvement in music > interpretation, but around 2x for the total time). I think the later > parts just benefit from the enormous heap because GC doesn't need to run > at all? But that's not really the idea of this patch, is it? > > In part, it actually is. If you have a lot of RAM, you should use it instead of trying to waste CPU cycles recycling it.
do you have a pointer to the score for testing? Can you do some timings with different values for GC_MAXIMUM_HEAP_SIZE , eg. GC_MAXIMUM_HEAP_SIZE=100M Also, it would be interesting to GC_PRINT_STATS=1 and see how much time is spent in GC, and how much a typical GC runs reclaim across the process. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
