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. -- Han-Wen Nienhuys - [email protected] - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
