Possible bug in Rhino 8 Grasshopper memory management

Grasshopper
1

Hello,
I’ve used Grasshopper for over 10 years, developing plugins, etc, but recently switched to Rhino 8 and am surprised that there might be a new bug with respect to cached geometry.

What I observe is that geometry is being “embedded” into the Grasshopper file without me requesting it. Historically this only occurred if you right clicked on a component and selected the embed option. I actually don’t see that feature in the new version but I think it is occurring.

The end result of this is substantially degraded performance when working in Grasshopper, where simple changes to the script result in waiting for seconds for the system to respond. I’ve experienced this in the past when working with embedded geometry which is why I never, ever use it.

I can solve it by right clicking on script objects that supposedly have “referenced” geometry in them, clearing values, and resaving the file. This drops the file size from about 11mb to a few kb.

The embedded geometry only shows up on the second time opening a grasshopper file.

Here’s an example workflow for you to follow to recreate the issue:

  1. Find a mesh model of some size, that contains multiple submeshes within it
  2. Open Rhino, import the mesh
  3. Open a blank Grasshopper script.
  4. Add a mesh container to the script, and reference all the meshes in your model into this container.
  5. Save your GH script.
  6. Look at the file size, which will only be a few kb.
  7. Close Rhino, GH
  8. Reopen Rhino, the 3dm file, and the GH file
  9. Move the mesh container in the canvas, and resave
  10. Look at the file size. Your file size will be much bigger. In my case it went to 10mb.

This issue issue is particularly frustrating because it means that I’m constantly having to go through my scripts, clear all values, and re-reference them whenever I reopen Grasshopper, because if I leave “embedded” geometry the response time in my GH scripts is interminably slow.

2

Hi Sruedisu,

I’ve reopened the original Youtrack that David created with a link to your comments to discuss our options.

1 Like
3

thanks @Japhy .
I suspect that the performance degradation may have to do with the time it takes to autosave once you have “internalized geometry”. I like that GH autosaves after just about any change, but if you have internalized data, the system has to re-save an entire model’s worth of data every time you move a single connection in the GH script.

If this is considered a “feature” of the new software, then perhaps an option to opt-in to the internalizing of data would help. I suspect a lot of people have this issue and don’t know it.

1 Like
4

The change and subsequent file size might be causing the issue. It looks like that change was required for assemblies and ghdata workflows. We’ll know more when David gets back from holiday.

I have found in large projects you almost have to disable Autosaves (in previous versions as well)

image
image840×411 49.1 KB

1 Like
5

This is fixed in 8.11.

2 Likes