Here is what I think I found:
- the larger part of this performance degradation is due to the cost of mimicking Grasshopper functionality, I presume due to creating lots and lots of components.
- if we use RhinoCommon for this operations, we start saving lots of time. We still do not get down to the same operational time as the “native” version, at least not if we do not have really a lot of meshes and really a lot of cores to use.
- the extra time is due to making data structures look GH-specific (creating GH_DataTree, or GH_Structure) after parallel execution.
- I think that, by fiddling more with this, we could get to similar timings as in the “native” version. Probably, we would have to use GH_Structure to avoid having Grasshopper making copies for us, or use some other tricks similar to this.
- the cost of parallelizing this operation seems to outperform the benefits so far.
- we might want to try to construct DataTree from several threads, but I do not think this structure is thread-safe.
So, all in all, this has been fun so far. I hope you guys can make something out of this, and with some more tweaks, make it even faster The best environment to make this really, really fast would in my opinion be a C# compiled component, though, given how things are set-up in Grasshopper.
It would be best to test for bottlenecks on a system with truly many cores, and with really many meshes (and meshes > 2*number of cores, of course).
for Robert McNeel & Associates
ghpython_2.gh (17.8 KB)