On 11/13/10 3:23 AM, "David Kastrup" <d...@gnu.org> wrote:

> Carl Sorensen <c_soren...@byu.edu> writes:
> 
>> On 11/13/10 2:01 AM, "David Kastrup" <d...@gnu.org> wrote:
>> 
>>> carl.d.soren...@gmail.com writes:
>>> 

>> 
>>> You sort the noteheads according to some criterion, and use the same
>>> criterion for sorting the other data structures according to their
>>> notehead anchors.  Then you have three lists, and you work off the
>>> notehead list, checking its current head with the other current heads,
>>> advancing the other lists when their heads get behind, and treating the
>>> association when the heads match.
>> 
>> I'd thought about doing this.  But I'm not aware of any criteria that
>> one could use for sorting in this particular case.  I'm not aware of
>> any index or property the grobs have that is sortable.
> 
> With non-compacting garbage collection, memory address of grob is a
> perfectly fine, if arbitrary, criterion.

Ahh, OK.  I see how that might work now.

Because this is not a simplification, but might be an optimization, I'll not
implement it now.  If we see the current code as a big time sink, and if we
see that implementing the sorting will reduce the time significantly, then
I'll consider it.

But I don't think this is a big time sink.  I think that enough care has
been taken to keep the loops short through the use of break, and the vectors
are small enough, that the speed should be acceptable.

Thanks,

Carl


_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Reply via email to