On Sat, Feb 5, 2011 at 1:51 PM, Mike Solomon <mike...@ufl.edu> 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 - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
<<attachment: c.preview.png>>
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
