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