GH run very slowly for thousands of geometry

Hi!

I’m trying to debug what in my GH script slowed the entire thing down (Editing text on a panel that’s NOT connected to anything takes 30s to take effect). Here are the two suspects:

1 I used 3000 or so little BREPs to split a large one. This of course is super slow, so I internalized the resulting thousands of BREP pieces into a pill, then disabled the Split component. The problem is the slow loading remains after disabling the component
2 I calculate the distance between the center of those BREPs to 4 curves separately

Keeping in mind that a personal machine should not do a distributed job, and that trees are not tensors, what could be going on here? Are all the calculations (besides split BREP) just looping through my thousands of geometry one by one?

Alternatively, does GH becomes ‘dizzy’ after doing a big calculation? (i.e. slowing down everything else unconditionally)

Thanks a lot!

Have you turned on the Profiler Widget? It will show you what components are taking the most time to complete.

Otherwise I’d recommend posting your script or a similar example script if you want more help.

https://discourse.mcneel.com/t/help-us-help-you/50034

1 Like

Thanks for your help Leo! I used the Profiler Widget to find as above that Split BREP was the slow component.

What doesn’t make sense for me is that working on unrelated components (e.g. a text panel that’s not connected to anything) is also slow.

I’m working with geometry I can’t share and lots of components, so, I’m trying to debug by getting a better understanding of how GH works.

The profiler doesn’t consider the time it takes to draw geometry in the Rhino viewports. If you disable the GH preview, is it still slow?

1 Like

Thanks for helping me David! By disabling preview, do you mean to hide everything (turn preview off for all)?

I know that if geometry from a Kangaroo solver is used, the incremental changes will slow things down. In this case, I disabled connections to the solver, so that no data goes into it (yellow wires), and its ‘On’ field is set to False. Perhaps under the hood, data is still entering the solver and taking up computer power?

In this case I meant just turning off the global preview for all of Grasshopper. It’s one of the buttons on the top right of the canvas toolbar.

1 Like

Thanks a lot! I will try that

Hi David, changing preview didn’t help but, I found the culprit–a huge Brep I internalized previously for checkpointing. Deleted it returned thing to near-instant response.

While this is a pretty dumb error, were there any tools that could have pointed me to this huge geometry? (its preview was off all this time)

No tools in regular Grasshopper. There may be something in a plug-in I’m not aware of.

But you’re saying that just having the Brep in the file made things super slow, even if it wasn’t getting modified? If so, that still sounds like a failure of the code. Any chance we can get that file so I can figure out why data which is not part of a solution is slowing things down?

1 Like

Thanks again for your help! I will ask my supervisor if it’s alright to share the geometry.

Information about it I can share right now, if it might help: the geometry is a ton of Breps (thousands) patterned on a surface with hundreds of control points. It was first created the same GH file and then internalized to checkpoint the progress.

Besides unrelated functions slowing down, saving the file with minor changes e.g. changed one letter in a panel that’s disconnected from everything else, also takes 30s or more.