Re: Grow heap aggressively during music interpretation (issue 561390043 by address@hidden)

[jonas . hahnfeld]

I just tried to reproduce the timings for commits already in master and
this patch. To be honest I don't see a clear picture yet.

Yes, this change seems to improve the time spent for garbage collection,
but the real time reported by "time" only decreases by a fraction (less
than 50% of the saved time for gc). Also I consistently measure
increased total and gc time when toggling the setting of the initial
heap size, ie the change in master actually makes it slower for me.

My conclusion would be that we need to measure larger scores, not
executions less than 10s. This may be the use case that most users care
about, but AFAICS it's actually pretty hard to get reliable data for
now.
I've tried to use the MSDM example from
https://lists.gnu.org/archive/html/lilypond-user/2016-11/msg00700.html
which runs for around ~40s on my system, but it crashes with Guile 2.2:
GUILE signaled an error for the expression beginning here
#                                                                       
                                              
 (define-music-function (parser location )()                            
                                              
Unbound variable: ol

Should we maybe prioritize correctness over performance for now?
Comparing performance with a fully working LilyPond should be much
easier.

https://codereview.appspot.com/561390043/