Closed polyline extrude to point - invalid mesh (python)

[AndersDeleuran]

@crz_06

Interesting how the computation speeds are so different.
Also between old and new python nodes

From my testing, CPython 3 that implements RhinoCommon will be slower than IronPython, and IronPython is in turn slower than GHPython:

Rhino 8 Regression: CPython/IronPython RhinoCommon Performance Is Worse

Hi McNeel, I’ve noticed that CPython scripts will perform substantially worse when implementing RhinoCommon than IronPython (presumably because of Python.NET) . And that the new script editor with IronPython performs slightly worse than GHPython (presumably because of the new editor, since they’re both running 2.7.12 .NETCoreApp). Here’s a quick demonstration making a whole bunch of Point3d within for loops: [2024-02-05 14_54_27-Grasshopper - 230801_ScriptsMillionPoints_00_] 230801_ScriptsMi…

In some tests drastically, so if you’re going for Python + RhinoCommon + speed I’d recommend sticking with GHPython for now. And as always, following a few simple tricks can affect performance by a lot:

Grasshopper Performance - Scripting Slower Than Native Components?

Specifically for GHPython, you can usually achieve considerable speed boosts on large inputs by not using type hints or the implicit Grasshopper cycle functionality (i.e. set the access type to List if you’re operating on a list and implement the loop yourself), and on large outputs by wrapping the data in appropriate Grasshopper types: [2021-04-29 09_09_17-Grasshopper Python Script Editor] Mesh Point Remap - multiThreadTest-minimumViableFile_GHPythonFixes_00.gh (1.6 MB) See this old thread…

Also, in this case a performance bottleneck is calling Mesh.Append many times within the loop. If we do that just once, or alternatively wrap the pyramid meshes in the Grasshopper mesh type, the compute time drops quite severely:

270710_MakePyramidMeshes_AHD_01.gh (730.9 KB)

Note how the viewport is a lot more responsive if we only output one mesh for all the pyramids.