Re: Introduce Beam_scoring_problem::quant_range, for quickly filtering out invalid positions. (issue4129050)

[Han-Wen Nienhuys]

On Sat, Feb 5, 2011 at 1:51 PM, Mike Solomon <address@hidden> wrote:

>>> True, although I think it's important to account for all beaming cases if 
>>> possible.
>>
>> This is a performance optimization, ie. a way to run collision
>> detection without performance impact if the object does not really
>> collide, so it does not need to deal with all cases.
>>
>
> From reading the code (correct me if I'm wrong), the upper collision in the 
> attachment would be taken into account because its stems all point in the 
> same direction, whereas the bottom one would not because its first and last 
> stem do not completely reflect the beam's stems' directions.

?

I'm intending to short-cut situations like the one in the image
attached; the lower note head is outside the range allowed for the
beam, so it makes no sense checking it for collisions.

> Is there any way that I could measure what type of performance hit LilyPond 
> is taking with this more robust beam-collision code?  I am not really 
> qualified to speak to what type of trade-off is acceptable, but it'd be good 
> to have an actual benchmark to make the comparison.

You can get a rough impression using ly:beam-score-count.  Another
option is to run a profile on a beam-heavy piece.  The last time I did
that, IIRC, beam scoring was ~ 10% of total time spent: not enough for
it to be worth optimizing a lot, but important enough that making it
much slower will be noticeable.  This was a long time ago, so, the
balance of expenses may have changed though.

--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

c.preview.png
Description: PNG image