Han-Wen Nienhuys <[email protected]> writes: > On Mon, May 14, 2012 at 3:04 AM, David Kastrup <[email protected]> wrote: >> >> "[email protected]" <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
