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/
