Re: Checks for recursive element behavior (issue 6943072)

[dak]

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.

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.

https://codereview.appspot.com/6943072/