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#.
