Re: Issue 1926 in lilypond: 2.15.12 processing speed problems

[mike]

On Sat, 24 Sep 2011 15:45:52 +0000, address@hidden wrote:
> Comment #1 on issue 1926 by address@hidden: 2.15.12
> processing  speed problems
> http://code.google.com/p/lilypond/issues/detail?id=1926
>
> Mike said:
>
> > 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 tried paper-twosided.ly using the 2.15.11 and 2.15.8 binaries for 
> Windows
> and found no significant differences in the compile times, c. 25s 
> each.  But
> 2.15.12 took around 60s, so I can confirm the slowdown in the GUB 
> binaries.
>
> Mike: try checking the commit corresponding to 2.15.12:
> 63cfd5548c42a98c7dae43f1f92e67772969e53c

Just tried it - the compile time was 4s.  Way strange...

> Maybe the slowdown is not apparent in current master.
>
> > 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).
>
> Trevor

> https://lists.gnu.org/mailman/listinfo/bug-lilypond

I know this may sound ridiculous, but how possible is it to do a git 
bisect with GUB binaries?  As I can't reproduce the problem on my 
homebrewed version, perhaps the only way to find it is by examining the 
binaries.

Alternatively, would it be possible to make another release and see if 
the problem is still there?

Cheers,
MS