Re: Plan for discussions

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Mon, May 14, 2012 at 3:04 AM, David Kastrup <address@hidden> 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%.  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
> ..
>> where a new string is getting allocated for every rest.  There is a lot
>> of potential for streamlining stuff before one caches it.
>
> Run a profile. These examples may not be the pinnacle of elegance, but
> unless you can measure it makes any difference, we shouldn't bother
> optimizing it.

I did once.  IIRC, the parser spends a large fraction of its time in the
routine reading a single character.  So for speeding up the parsing
speed, working on the I/O aspect might be an effective measure.  Of
course, the interpretative stage tends to take more time than the
parsing.

-- 
David Kastrup