Hi Everyone! I’m trying to write a parallel Ghpython component that could solve a computationally heavy MeshRay function, but I keep getting slower results with it than with the native Grasshopper MeshRay module. 57ms for the Grasshopper module, 2.4 seconds for the Python component. My computer h…

Hi, I’m experiencing something really simillar. When I run MeshRay directly in Grasshopper, it takes approximately 50ms for 2500 repetitions. But when I run it using ghpythonlib components (MeshXRay) in Rhino Python Editor it takes 120 ms for 1 repetition! Do anybody know, where could be the probl…

While you’re waiting for an answer here have a read of what was said on the GH Forum about Parallel Python Components being slower

Thanks Danny, but I’m experiencing this even without using parallel component. The problem should be somewher in the MeshXRay I guess. Tomas

Tomas, I’ve been over it many times since I initially posted, and can’t seem to find any reason why it performs so poorly compared to the native Grasshopper component. I’ve also tried with the Occlusion function with similar results. It seemed to me as though MeshXRay would be a perfect candidate …

Hello everyone, occasionally somebody posts this kind of results, and I’ve noticed that very often this has to do with speed-up structures that are used to make finding points faster. For example, Gwyll, in this discussion , was experiencing exactly this. I will have a look at this case now - and …

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 s…

It is true that datatrees are not threadsafe, and they still aren’t threadsafe in GH2 (it’s actually the first class I’ve redesigned). I’m not sure what it would take to make them fully threadsafe, and how those changes would impact regular performance. However in the case of threaded python compo…

[image] DavidRutten: properly profiled before we start typing up optimizations. Ah… Rutten’s rule #2 - profile first, optimize second

Yeah, I’ve profiled, like always. The findings above come from that. Rebuilding the DataTree class takes about half the time of the whole script on my machine. Is there something like SetBranch() on DataTree that would not copy the whole data? AddRange is the only real method that is called in that…

There’s probably about 5 things that currently happen when using a GH component from python that don’t actually need to happen. Continually constructing components anew and continually creating new documents for them to reside in only to destroy those instances a moment later would be one thing that…

Ghpython - Parallel Component Slower than Native Ghopper Module

Grasshopper

dannyboyesiom March 27, 2014, 10:23pm 9

Ah… Rutten’s rule #2 - profile first, optimize second

Topic		Replies	Views
New ghPython with Node-in-Code and Multi-threading News	53	14706	October 9, 2014
Grasshopper Performance - Scripting Slower Than Native Components? Grasshopper windows , rhinocommon	17	3187	May 13, 2025
New version of ghpythonlib.components Serengeti (Rhino WIP) ghpythonlib , grasshopper , python	20	35627	November 10, 2016
Testing ghpythonlibrary_parallel on node in code Grasshopper	0	327	March 20, 2021
Computational speed Python vs. Cluster Grasshopper windows	5	2298	July 28, 2021

Ghpython - Parallel Component Slower than Native Ghopper Module

Related topics