When a big project is being processed, the parsing and rendering of hundreds of files can take quite a bit of time, even before lilypond starts compiling the rendered code. For example, BWV 247 takes over 20 seconds to parse and render, and even that after being parallelized (see #5).
A way to improve this state of affairs is to cache the results of each step, using temp files.
For parsing, it's rather simple:
The source lydown file is read.
A hash for the content is calculated.
Lydown searches for a corresponding temp file (e.g. .parse)
If a temp file is not found, the content is parsed into a lydown event stream, then written to the temp file using MsgPack encoding.
If the temp file is found, its content is parsed using MsgPack.
For rendering, it's a bit more complex, since we need to take into account the state of the work context, so:
The hash value for the work context is calculated => h1.
A hash for the lydown event stream is calculated => h2.
Search for corresponding temp file:
.
.render
.
If the temp file is not found, the stream is rendered, then written to the temp file using MsgPack encoding.
If the temp file is found, its content is parsed using MsgPack.
When a big project is being processed, the parsing and rendering of hundreds of files can take quite a bit of time, even before lilypond starts compiling the rendered code. For example, BWV 247 takes over 20 seconds to parse and render, and even that after being parallelized (see #5).
A way to improve this state of affairs is to cache the results of each step, using temp files.
For parsing, it's rather simple:
For rendering, it's a bit more complex, since we need to take into account the state of the work context, so:
.
.render