FreeCAD
- chicken-egg-tree.png (116.4 KiB) Viewed 1112 times
Maybe it can be made faster by going the other way around? i.e. when adding an object as child of something, and withdrawing it from root, look up the ultimate parent of something and check if it is the child being added? This way, the performance penalty is proportional to depth of tree, which isn't going to be too big anyway?realthunder wrote:The cyclic check only happens when a free item (i.e. an item at document root) is newly claimed, which already has children. The check needs to visit all its children. That's the only case requiring a check.
So as far as I understand, it's pretty rare, so can be ignored.realthunder wrote:The cyclic check only happens when a free item (i.e. an item at document root) is newly claimed, which already has children. The check needs to visit all its children. That's the only case requiring a check. We'd be creating new items (without children obviously) for all other cases. So, I think the performance impact should be limited.
I doubt there is any shortcut. When reparenting the root item, you'll never know what's in its children until a full visit.DeepSOIC wrote:Maybe it can be made faster by going the other way around? i.e. when adding an object as child of something, and withdrawing it from root, look up the ultimate parent of something and check if it is the child being added? This way, the performance penalty is proportional to depth of tree, which isn't going to be too big anyway?
n! !?? If so, it's awful, since factorial of just 13 is already over 1G. And a factorial of 20 will take about 100 years to traverse.realthunder wrote:visit each children recursively (that's factorial n! maybe?)
Oops, I mean 1+2+3..+n, not multiple, n(n+1)/2. This is the case where all child items are loaded before its parent.DeepSOIC wrote:n! !?? If so, it's awful, since factorial of just 13 is already over 1G. And a factorial of 20 will take about 100 years to traverse.realthunder wrote:visit each children recursively (that's factorial n! maybe?)
Haha, that's just O(n^2), which is a heaven of a difference compared to the factorialrealthunder wrote:Oops, I mean 1+2+3..+n, not multiple, n(n+1)/2.
.
This is desired IMO, because visibility of body used for boolean operation does not depend on visibility of the body that contains the Boolean operation. But according to code, Part shouldn't claim the used body as child anymore, so there is likely a bug somewhere.NormandC wrote:tl;dr: bringing an inactive Body into an active one using a Boolean operation feature seems to create a second instance of the "imported" Body. IMO this is not desired,
