[Top][All Lists]
[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