Re: aux files to cache compilation info

[address@hidden]

On 6 août 2012, at 23:23, Graham Percival <address@hidden> wrote:

> On Mon, Aug 06, 2012 at 08:36:05AM +0100, Ramana Kumar wrote:
>> In this message on users
>> http://lists.gnu.org/archive/html/lilypond-user/2012-08/msg00094.html
>> Mike mentioned the possibility of generating cache files to speed up
>> recompilation. He also said working out the details might take months
>> of discussion.
> 
> I slightly disagree with his caution there: although a stable API
> for the line-breaking would be necessary to keep it working
> between lilypond versions, I don't see that as a major concern.
> If somebody updates their version of lilypond, I don't think it's
> asking too much for them to regenerate their score from scratch.
> 
>> People seem to agree that line breaking is the major bottleneck in
>> compilation. What would it take to cache just line breaking?
>> 
>> I suggest there are at least (and probably exactly) two things the
>> cache needs to contain:
>> 1. enough information about the last score compiled to know where the
>> new (current) score differs
>> 2. line breaking information for the cached score
> 
> I'd suggest an alternate method: the cache needs to contain:
> 1. the bar numbers of page breaks for the last _full_
>  compilation of file X
> Then the "quick" recompile simply re-uses those exact bar numbers
> for the line-breaks.
> 

This would be rather straightforward to implement assuming that any additional 
bars would just get tacked onto the last line or a new line.
In big scores I see this cutting compilation time in half.
I can imagine this being flawless for 99% of "add a staccato" scenarios.  Once 
we're in the full-measure territory, it'll create sub-optimal typesetting.
We're actually not too far from this, as there is a single function that takes 
line breaking info and splits systems accordingly.  We just need to override it 
such that the user can pass it data.

What we can't speed up with this method is parsing, interpreting, drawing 
systems and the various backends.

Cheers,
MS

> Undoubtedly David or Han-Wen is going to come and say why this
> won't work, but barring any such activity, I'd suggest that the
> next step is to "get one's hands dirty" and implement this.  I'm
> sure that unforseen issues will arise in the process of doing so,
> but to my naive eyes this seems like a fairly low-hanging fruit,
> which could save lots of time in the final stages of work
> (tweaking slurs, adding fingerings, etc).
> 
> - Graham
> 
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel