lilypond-devel
[Top][All Lists]
Advanced

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

Re: Speed tips, again, for extremely large scores?


From: Joe Neeman
Subject: Re: Speed tips, again, for extremely large scores?
Date: Mon, 01 Feb 2010 18:53:05 -0800

On Sat, 2010-01-30 at 16:08 -0500, Trevor Bača wrote:

> On Sat, Jan 30, 2010 at 12:59 PM, Graham Percival
> <address@hidden> wrote:

>         Since then, we've had
>         - skyline vertical placement  (you don't need to manually
>         increase the
>         padding on text scripts!)
>         - better vertical placement of systems on a page (maybe not
>         particularly relevant to huge scores when you can only fit one
>         system
>         per page anyway)
>         
>         Both of those are expensive.
> 
> 
> Ah, good point, on both counts.
> 
> 
> The score in question contains no scripts. Hmm ... isn't there a way
> to turn off skyline vertical placement?

I very much doubt that this is the problem. If you compile your own
lilypond, you can include profiling support with the --enable-profiling
option to ./configure, which would tell you where the bottleneck is.
>         
>         > (As a postscript, I also have #(define page-breaking
>         ly:minimal-breaking)
>         > set in the score because I set all breaks and vertical
>         spacing by hand. I
>         > know that certain changes that Joe's made to dramatically
>         improve vertical
>         > spacing cane be time consumptive in some cases, so maybe
>         this is a
>         > precaution to ward against that. However, the setting
>         produces no obvious
>         > increase in performance, which makes me think that vertical
>         spacing has
>         > nothing to do with the performance difference I'm
>         experiencing.)
>         
>         
>         Hmm.  1) are you sure that minimal-breaking is the lowest-CPU
>         option?

I believe it is the fastest, although I've never checked.

>         Isn't there a naive-breaking, or even a
>         non-automatic-breaking ?

There isn't, but one could probably be written. For it to be much faster
than minimal-breaking, it would need to avoid all of the
height-estimation routines. That is, it would need several changes to
the existing code, so it wouldn't quite be trivial.

>           If
>         you've manually set *all* breaks and pageBreaks, then
>         theoretically
>         that would save a **ton** of CPU resources.

Probably. But it would be nice to have profiling output to be sure.
> 
> 
> Actually, you're right: I'm not certain. I was assuming that minimal
> would be the least CPU-intensive option, but I may be wrong. (I've
> added Joe to the thread in the hopes that he might weigh in.)
> 
> 
> 
> 
>  
>         2) are you certain that you've defined this in the right
>         place?  I'm
>         not suggesting that *I* know the right place, but I'm not
>         certain if
>         you're supposed to add this to the top of your file, or inside
>         the
>         first \book{} block, or put it in every \score block, or what.
> 
> 
> I've currently got the minimal page-breaking setting defined in the
> top-level \paper-block in the file (which is also the only
> \paper-block in the file). I'm 82.63% certain that that's the correct
> place.

The console output differs between minimal-breaking and
optimal-breaking.

Cheers,
Joe







reply via email to

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