What makes Solid.ByUnion so expensive for performance?

Hi folks,

One of the easiest way to trim surfaces in Dynamo for Alias is to use the Surface.SubtractFrom node. For that, I take a number of solids, and make them one using the Solid.ByUnion node. This works fine in general, but becomes really slow really fast, once you go beyond a hundred solids.

Question: what is the expensive part of this operation?
Because: if the expensive part is checking for a potential intersection of the solids to join, I would really, really like to have an option or a separate node which skips this check.
Scripts are taking minutes or even longer to succeed, just because of this node, so any possible improvement here would hugely benefit a lot of Dynamo scripts!

Try to carefully move the slider beyond 10 in this script, and you will see what I mean. :slight_smile:

Thanks,
GG

Solid-Performance-Test.dyn (47.3 KB)

Leaning towards memory consumption.

Curious, do you get better results if you flatten the list first?

Memory consumption seems not to be the problem, the performance already gets much worse before a significant rise of memory usages happens.
Flattening the lists before doing the union makes things even worse (a lot!).

Ok - then I am guessing it is the complexity of the operation causing a memory consumption issue.

This is all a guess as the core geometry operations are not open sourced. But in review I think that each boolean operation has to check for solid 1 and solid 2 to get solid X. Then solid X is checked against solid 3 to get solid X. Then solid X is checked against solid 4 to get x… Eventually solid X is checked against solid N to get the final result. After each step in the calculation the proceeding data is removed, but there is still only so much data which can be stripped as it goes along the way.

Which build of Dynamo are you testing in?

The team is looking at performance so will flag @achintya_bhat and @solamour on this one.

We’ll take a look at this GG - thanks for flagging :slight_smile:

Hi GG! Team has been investigating this specific function recently. The Solid.ByUnion node gets slower with more solids because it repeatedly copies and deletes intermediate bodies during union operations. We are looking at working on optimizing this. More updates to come in the future on this. Thanks for sharing your example, we will use this as we investigate further and optimize.

FYI @Aparajit_Pratap

Thanks everyone!