Re: [Lilypond-auto] Issue 2527 in lilypond: Finger-flag collision

[lilypond]

Updates:
        Cc: address@hidden

Comment #61 on issue 2527 by address@hidden: Finger-flag collision
http://code.google.com/p/lilypond/issues/detail?id=2527

Ok, by now I am for reverting.  I just found the following in the patch:
+// If the grob array is unordered, we assume that duplicates should
+// be removed. This makes sense for things like side-position-elements,
+// which may be added recursively numerous times and thus will eat up
+// computation time when skylines are calculated.
+// If the array is ordered, then we don't remove duplicates.
+
 void
 Pointer_group_interface::add_grob (Grob *me, SCM sym, Grob *p)
 {
   Grob_array *arr = get_grob_array (me, sym);
   arr->add (p);
+  if (!arr->ordered ())
+    arr->remove_duplicates ();
 }

 void
@@ -81,6 +89,7 @@ Pointer_group_interface::add_unordered_grob (Grob *me,  
SCM sym
   Grob_array *arr = get_grob_array (me, sym);
   arr->add (p);
   arr->set_ordered (false);
+  arr->remove_duplicates ();
 }

What does this mean?  It means that remove_duplicates is called for every  
grob added with these functions, meaning O(n^2 log(n)) computational  
complexity.

In particular with things like \RemoveEmptyStaves, this makes LilyPond  
unsuitable for large scores.

This patch needs to be done properly, split into sensible and independent  
commits, and reviewed carefully.  All this has not been done and we are all  
at fault for it.  Apart from all the bad other side effects we've seen so  
far, this performance problem resulting from a mismatch of the used data  
structures with the desired behavior is just totally inacceptable for a  
stable release.

LilyPond _has_ to remain usable for things like an opera or symphony.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings