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

[David Kastrup]

address@hidden writes:

> 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

The preceding line is

col =

so this is likely a matter of passing the wrong part of the file into
Guile when encountering # .  The file contains two 3-byte UTF-8
sequences above which could be thought to throw off the interpretation
by 4 bytes.  But it actually is off by 6 bytes if it is running into the
preceding "ol", as if the special characters/bytes are not seen at all.

-- 
David Kastrup