Re: Sibelius Software UK office shuts down

[address@hidden]

On 5 août 2012, at 12:37, Joseph Rushton Wakeling <address@hidden> wrote:

> On 02/08/12 17:51, Graham Percival wrote:
>> In short: if there is a concerted effort to create a "quick
>> render" output, I would be absolutely shocked if it wasn't at
>> least 10 times faster than the current output.
> 
> (1) How paralellized is the current code -- and if not much or at all, what 
> do you think the scope is for doing so?  E.g. once basic pagination is in 
> place, could all other elements be engraved in separate per-page threads?  
> Likewise, any parts of a score separated by an explicit page break could be 
> engraved by separate threads.
> 

LilyPond currently only works on a single thread and the code base is 
definitely not optimized for parallel processing.  GCC may do this 
automatically when compiling LilyPond (I'm not sure how GCC works).  There are 
many places where parallel processing could be implemented in LilyPond - 
outputting broken lines and pages, as you suggest above, is one of them.

> (2) Are there any statistics on compile time vs. input file size?  It doesn't 
> necessarily help Lilypond to be blazingly fast on a 2-page, 4-part choral 
> score if it's horrendously slow in a 100-page full-orchestra operatic score.  
> I recall that Valentin's opera was a nightmare to render both in terms of 
> time and of memory used along the way.

In 2.15 we did some profiling on this a while back and sped this up 
considerably (there was a bottleneck in the code) but we haven't done any 
speed-up here since then.  I think LilyPond line breaking is O(n log n), 
although someone more into CS than I would have to confirm this.

> 
> (3) The real speed issue is not so much from-scratch compile times but 
> recompile times -- how long _should_ it take to re-render the score if e.g. I 
> add a single staccato dot to one note?

One idea for LilyPond that has been kicked around for a while is that of .aux 
files.  LaTeX uses these and they help speed up compilation on second passes 
(they also make it more accurate).  The problem is that LilyPond currently has 
no API - it would take a few months of a few developers time to nail down a 
core API so that .aux files could be used predictably and without the creation 
of too many exceptions.  This is a high priority of mine but it is a bit too 
big for me these days and I've got my hands full w/ skyline work :-(

Cheers,
MS

> 
> Sibelius' publicity always used to make much of the fact that if Wagner had 
> wanted to add a new bar at the start of the entire Ring Cycle, using Sibelius 
> it would have taken no more than 1 second.  That kind of speed-of-tweaking 
> may be worth more than speed of first compile -- ideally, you'd be able to 
> type stuff into the editor in e.g. Frescobaldi, and see the score change in 
> front of your eyes.
> 
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user