Somebody had a post on here a while ago about the speed of Houdini vs Grasshopper so i’ve been doing some tests… This is creating a grid of grids using some different methods. I don’t quite understand why it’s so slow since it is essentially some basic math.
Because it’s all done in one process, that’s why. It is Rhino performance issue.
I have a few performance reports that got no answer from McNeel.
I think they should focus on creating new process for every plugin, for starters.
Sometimes forum oldtimers here are bored and like to parttake in “optimization contests” trying to speed up specific tasks. Who knows, perhaps you can get someone interested. But you are more likely to get a response if you attach your GH file so that others would immediately see exactly what you are after, and so that they wouldn’t have to recreate what you have already done.
Typically a script could potentially speed things up significantly.
I also think the way you are doing it is quite heavy as well in logic. For instance this took only 9ms.
It’s just an example. I’m not trying to create a grid of grids but just highlight how everything gets slow so fast. It’s strange that multiplying some numbers takes so long. The array function seems to be much faster than orient, so it’s nice here, but at a certain point that craps out as well. Try dragging the slider up
Houdini craps out also it depends what you have displaying and how optimized your logic is. I have a good computer though so I can go pretty high, probably not the best bench mark. Math on lots of doubles with long decimal point values (like points x,y,z) are usual heavy in code. Array is faster than orient because it does less work. It is just a displacement. It doesn’t have to also check orientation, even if there are none it still has to check. Move is most likely faster than orient also. Use orient when the orientation needs to change to a different plane system.
I’m pretty sure its not the implementation of program A versus program B which has a significant impact on performance. Especially on “basic operations”. This is micro optimisation you are talking of.
Language performance is overestimated, parallel processing is overestimated, even bottlenecks are not identified correctly.
You should rather care about writing good definitions/code and use fast algorithms. If you need real-time performance then Rhino/Grasshopper isn’t the tool of choice anyway. CAD related automation is always delayed. And you know, who cares if your definition calculates within 1 second or 1 minute, if you save 10 hours of boring, repetitive work? In the end it matters if are you able to produce what you had in mind/is needed.