Tree Branch component: SLOW

The Tree Branch component is cripplingly slow–4+ seconds in the below function. I’m sure it would be much faster in C#, but I’m struggling with the documentation for manipulating tree structures in that code. Anyone know of ways to speed this component up or translate to C#?

Hello,can you upload gh file?

Hi Masaki,

Attached is a simplified, annotated version of the GH file.

temp.gh (50.7 KB)

Hi Daniel,

There was a null, so I removed it and then programmed it.

Now that we have the program in C#, you can parallelize it if you want to make it faster.
I am not fluent in English, so comments in the script may be incorrect.

temp_Re.gh (80.3 KB)

Masaki, wow, thank you, this is great!

I did more testing, however, and it looks like the Depath component, which is required with your C# (previously, the native Tree Branch was deconstructing paths) adds back the time saved. I suspect this may have been the slowdown within the native tree branch selector as well–likely in other tree operations as well (see: Replace Paths)

In my case, the list of paths is compiled from a series of ints, so I was able to simply weave the ints together (~734 ms weave component, not shown), feed these ints into the “dePath list” relay in below image, and retain most of the time saved by your c#.

In my case, I still need the list of constructed Paths elsewhere, so I’m doing double work by creating a woven list of path ints (734 ms) in addition to a list of regular paths (800ms), but it is still a substantial time saving when applied to big amounts of data (see image below). Note in building the list of paths, I find using concatenate is way faster than using construct path. Likely for the same reason depath is so slow. Similarly if I use the “split text” component to break apart paths into ints, it’s way faster than depath. In this instance, however, weaving a separate list of ints (fed into the Depath list relay) is the fastest way I’ve found to get inputs for your c#.

1 Like