Re: Plan for discussions

[address@hidden]

On 14 mai 2012, at 08:04, David Kastrup wrote:

> "address@hidden" <address@hidden> 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%.

I said "by" 1/5, not "to" 1/5 :)

> 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.
> 

The parser is pretty fast actually.  The interpretation stage seems like the 
part of LilyPond that is most ripe for an overhaul, especially in polyphonic 
music, where it can slow down significantly.

Cheers,
MS