"m...@apollinemike.com" <m...@apollinemike.com> writes:
> One idea I've been a fan of for a long time is some type of aux file
> system in LilyPond. That is, if we can come up with a file format
> that stores loads of data from previous runs of a score and then can
> somehow compare it to a parsed file, it could cut compilation time
> down by about 1/5 for stuff like changing B to B-flat in the Mahler's
> 9th. I say 1/5 because the line breaking would need to be redone,
> which means everything afterwards needs to be redone, but the
> interpretation stage could likely be cut down.
The interpretation stage does not take 80%. If you want to speed it up
significantly, work on the input system. LilyPond spends most of its
time IIRC in the routine reading a single character, because parser and
Scheme read routines are more or less working independently and are
exercised in parallel all the time. Stuff in lexer.ll like
for (int i = 0; i < n; i++)
{
yyinput ();
}
char_count_stack_.back () += n;
does not exactly look like the height of good design. There are also
things like
<chords,notes,figures>{RESTNAME} {
char const *s = YYText ();
yylval.scm = scm_from_locale_string (s);
return RESTNAME;
}
where a new string is getting allocated for every rest. There is a lot
of potential for streamlining stuff before one caches it.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
