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

[Han-Wen Nienhuys]

For testing, use

https://github.com/hanwen/lilypond/tree/guile22-experiment

in particular, you need

https://github.com/hanwen/lilypond/commit/b696550379831ecec1519be6d59cd8a3003e5329

for the UTF-8 parsing. I fixed this a week ago, but due to  the delays
in getting the preceding fix in ("cleanup embedded SCM parsing"), I
couldn't send that for review yet.

For me, juggling 15 different outstanding code reviews at the same
time is the bane of the current development process.

On Sun, Feb 2, 2020 at 9:51 PM David Kastrup <address@hidden> wrote:
>
> 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



-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen