lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: aux files to cache compilation info


From: Graham Percival
Subject: Re: aux files to cache compilation info
Date: Mon, 6 Aug 2012 22:23:36 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]