lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Checks for recursive element behavior (issue 6943072)


From: address@hidden
Subject: Re: Checks for recursive element behavior (issue 6943072)
Date: Sat, 22 Dec 2012 09:29:48 +0100

On 22 déc. 2012, at 09:25, address@hidden wrote:

> On 2012/12/22 06:41:06, mike7 wrote:
>> On 21 déc. 2012, at 10:09, mailto:address@hidden wrote:
> 
>> > On 2012/12/21 07:59:02, MikeSol wrote:
>> >> Hey all,
>> >
>> >> I'm ok w/ this on the countdown but can someone check out David's
>> > suspicion that
>> >> this slows stuff down by O(n^3)?  I definitely won't push this if
> it
>> > slows
>> >> LilyPond down to a crawl.
>> >
>> > I am not ok with that.  It looks really, really, really expensive.
> I
>> > don't see what would be wrong with just setting a context property
> flag
>> > axis-group-active in the engraver and refuse to maintain an axis
> group
>> > if the flag is already set.
> 
>> In general, elements should never recursively be elements of
> themselves.
> 
> Either grobs being elements of other grobs are a frequent occurence, in
> which case going through _all_ elements recursively each time in that
> particularly expensive way of unpacking them into a throw-away array is
> really wasteful, or they aren't, in which case we should just bother
> with those cases which actually act as grob containers.

All grobs that have an element list are, by definition, implementing 
axis-group-interface and are thus grob containers.  The recursion through the 
elements list happens at the time of adding, not each time the element list is 
accessed.

> 
> If we are talking about a general recursion-blocking mechanism, there
> are much, much, much, much more efficient ways than going recursively
> through the whole data base in an inefficient way (allocating and
> throwing away arrays temporarily on the heap) for every new element.

Where in the new code are things being allocated and thrown away temporarily on 
the heap?
If there is a more efficient way to implement this patch, let me know.  It 
seems, though, that the only way to prevent grobs being elements of other grobs 
is to prevent grobs from being added to elements lists à la this patch.

Cheers,
MS


reply via email to

[Prev in Thread] Current Thread [Next in Thread]