Optimum Python Scripting and Iteration

Hi, is there a consolidated resource for advising on the optimum python development?

Currently I’m using the rhinoscriptsyntax module because it was the first example code I found. The Rhino module looks like it has more functionality but isn’t easily interchangeable with rs, and is a bit more verbose in code. If it won’t give me a performance boost, I hesitate to move over to it unless it’s highly recommended.

I’m also having to restart the whole app when I make changes to most of the code (since it’s in modules for organization and readability sake). If there’s a way to reset the python engine while the app is running, I’d love to know it.

I’m doing mostly Boolean operations on polysurfaces. I’d love to speed that up as much as possible.

I’ve got an M1 mac currently and it’s decently performant with Rhino (which makes me happy), but if a windows machine is benchmarked as much much faster, I can look into that.

My project runs for about 15 min currently and processes around 10k solids (not meshes).

Any advice would be greatly appreciated, thanks!

Here’s a few points to consider:

And some simple tips on speeding things up:

Also, you might be able to multithread your code:

Edit: Apologies, this is for GHPython (though the RhinoCommon points and multithreading are still valid). Hadn’t had my coffee yet :coffee:


If you mean rhinocommon, yes, it’s recommended, although keep in mind that rhinoscriptsyntax is just a wrapper for rhinocommon in the first place.

I don’t know about Rhino, but at least in Grasshopper - in my experience -, reloading or deleting and reimporting the Python module doesn’t seem to work. Restarting is annoying (but at least macs have those super fast SSDs)! I’d try it to make sure though.

If possible you could look for alternative, less costly workflows. Boolean operations are expensive, especially for polysurfaces.
It’s hard to give advice without knowing what you do exactly!

That sounds ludicrous! :smiley: Have you looked into multithreading yet?

Can you share an example? Also read through the resources that Anders has provided above.

1 Like

Probably only a fraction of the extra time is due to rhinoscriptsyntax, but it doesn’t hurt to try the RhinoCommon approach. I would recommend placing a breakpoing on a rhinoscriptsyntax function that you are calling and step into the code while debugging to see the exact RhinoCommon functions being used. This is a good way to get a better understand of how RhinoCommon is used for specific tasks.

There is a reload function in python that you could try using.

Thanks for the links, and yeah, even though it’s GH it’s still useful.

I’m not sure I can multithread in my biggest time-offenders, but I’ll take a look.

I’ve spent too much time trying to get the module reload functionality working nicely… I may look at it again someday. It’ll work sometimes and at other times it’ll put the python engine in an undetermined state… so I just don’t trust it at all anymore.

The closest example I have is a sphere with 10k cylinders attached to it at random positions/radii radiating out perpendicular from the sphere’s surface.

Sometimes these cylinders will intersect at seams and I’ll have to jitter them a little in an attempt to find a position “close enough” so it’ll “stick”.

Since these cylinders are all attaching to the same sphere, I don’t think I can make that parallel easily.

Each union takes longer and longer of course.

This is so much faster with surfaces than meshes BTW.

I’m going to try converting all my code to RC and do some optimization there.

See this tool for digging in to Rhinocommon from rhinoscriptsyntax

Do they all need to be random? Could you populate a small segment, then rotate and mirror, then finish of with some larger radii at true random positions?

They are, in fact, all unique projections. They are the locations of stars in the sky.

I’ve already been looking at the github repo for RS. I just didn’t really want to re-align my brain to using RC instead of RS :wink: