Grasshopper getting slow with larger definitions

Hey guys,

there is a very annoying issue I run into in grasshopper, when my definitions get larger:

The gh-interface keeps getting slower and slower, so connecting ANY component with another - be it just a slider which is being connected with a panel can take seconds sometimes.

Now I am working on a new project and the same thing is starting to happen again, the interface is already a bit slower, but is bearable, so I thought it is the right time to post here, before it gets worse. :stuck_out_tongue:

Is this a known issue, are there any workarounds (clustering, wire-preview options etc.)?

Any help would be much appreciated!

Cheers, Rudi

Ján Pernecký did a free webinar last weekend on the topic of speeding up gh definitions.

You can get a recording for free on his website
And here a short paper of the content of the webinar.

Hope it helps :slight_smile:


Wow. Thank you man, i´ll check it out!


Is your issue due to massive amounts on components (laggy UI), or is it due to calculation time?

The first half is good, the rest is micro-optimisation and rather irrelevant. The best advice when it comes to performance is using the right algorithm. Math,Logic and Knowledge are your best friends :wink:


@TomTom I fully agree :slight_smile:

My issure is with the amount of components! The profiler widget always shows a reasonable calculation time.

Split up the definition into smaller definitions for what each part does and develope a workflow between them.


Alright, sounds logical - thank you for the tip!

Is there maybe also a workaround, where I could e.g. stitch all those definitions back together?

Btw, I was recently working on a quite big definition, and the inferface got so slow that it took around 2-3 seconds to connect components - interestingly, by copy pasting the definition into a new file, everything worked perfectly fast… until I saved it as a new file - then it was slow again.
So because I didnt knew any better I just kept creating new files…

…maybe this can give some hints to the underlying problem

Are you using large amounts of internalized geometry? I found out that slows gh quite a bit, as well as using more than 1 image sampler component.

I don’t usually stitch them back together, kind of would defeat the purpose. I do things like bake out of one definition, reference into another definition. Or use stuff like the data input and output components. You could also use plugins like human which have nice ways to bake and reference to/from specified layers.


As Michael suggests, splitting up the definition into logical parts makes a lot of sense. If that isn’t possible for some reason, and you happen to have a lot of internalized geometry (probably not a good idea in hindsight), then watch out for the autosave on wire events.


We had a summer school workshop two years ago with a large design-for-manufacturing workflow that was accepting internalised geometry from other definitions. It turned out that the large amount of internalised data in the parameters, connected or not, was taking a while to save, resulting in a very frustrating definition. Turning off the autosave on wire events helped right away, as a temporary solution.


Thank you all for the suggestions!

Changing the autosave settings seems to have fixed it- the interface is perfectly fast now!


This was driving me crazy, thanks for the tip.