bug-lilypond
[Top][All Lists]
Advanced

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

Re: Issue 1926 in lilypond: 2.15.12 processing speed problems


From: address@hidden
Subject: Re: Issue 1926 in lilypond: 2.15.12 processing speed problems
Date: Sat, 24 Sep 2011 14:27:47 +0200

On Sep 24, 2011, at 12:43 PM, address@hidden wrote:

> Status: Accepted
> Owner: ----
> Labels: Type-Critical Regression
> 
> New issue 1926 by address@hidden: 2.15.12 processing speed problems
> http://code.google.com/p/lilypond/issues/detail?id=1926
> 
> On my system, 2.15.12 is _much_  slower than 2.15.10 for files of a fair 
> complexity.  The Mozart Horn regtest went from 14 seconds to 27 seconds.  A 
> 70 bar, 7 page piece by Parry I'm currently setting went from 23.3 seconds to 
> 49.3.  I've pasted below the worst increases in the regtests.  This will 
> probably be difficult to view, but may help debugging:
> 
> File  Old.Time        New.Time
> midi-scales.ly        3.13    6.89
> compound-time-signatures.ly   3.05    6.81
> paper-margins-line-width.ly   2.59    5.94
> page-turn-page-breaking-repeats.ly    2.78    6.42
> paper-twosided-bcorr.ly       10.02   23.27
> page-turn-page-breaking-auto-first-page.ly    3.02    7.16
> paper-default-margins-def.ly  3.33    8.14
> beam-auto.ly  5.69    13.91
> paper-twosided.ly     9.83    24.14

Here, on current master from my VirtualBox, paper-twosided.ly takes 8ish 
seconds with current master and 7ish seconds rewound to 
079a12b77ac95640595a6433761e7b46d5552af9 (the commit before the flag grobs).

paper-twosided.ly seems like the best test to tackle at first, as there are no 
flags & no beams, so the only thing from the stem/beam/flag work that could be 
slowing it down is the stem pure-height and/or height function (and their 
consorts of helper functions).  However, as I can't reproduce the large 
difference in compile times, it is difficult for me to start separating signal 
from noise in terms of what is actually taking longer.

I just read over the code in stem.cc for beamless stems and I don't see 
anything that could result in functions being over-called.  There are a few 
extra lookups in separate functions (for example, the beam object is looked-up 
more times), but I doubt this'd slow down the code a lot (I could be wrong - 
lemme know).

Are there any good profiling tools that'd help with this sorta thing?

Cheers,
MS


reply via email to

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