Over the last week or so I’ve been having some issues with GH and what seems to be a memory leak. I’ll launch Rhino with a default template, nothing in the file, and then launch Grasshopper and for about 2 minutes my CPU usage spikes for Rhino, hovering in the 5-10% range (8 core/16 thread CPU) before it finally settles down and I can use it without constant stuttering. During this 2 minute CPU spike, my memory usage also spikes and goes from sub 200mb for Rhino alone to over 15GB with GH open. Again this is with an empty Rhino file and no GH files open. Removing all plugins and UserObjects fromg GH doesn’t help. Unloading Grasshopper (GrasshopperUnloadPlugin) helps reduce the memory usage a little, but launching it again (same Rhino session) causes the same CPU penalty and my memory use doubles over what it was before, hovering around 31GB with nothing happening in the GH file.
After the CPU settles down I can use everything fine, but my memory is still stuck at around 15GB or higher for the rest of the session. Exact same thing happens in Rhino WIP once I launch GH from there. I’ve tried uninstalling the WIP to see if it helps, but no luck.
I’m on Windows 10, Rhino 5.12.50810.13095, 08/10/2015, Grasshopper 0.9.0076.
Here’s a video showing the startup process. Original video was right around 2:30, and sped up 8x to get it to 18s.
Hi @tlogan, it has been reported before, but I’ve never managed to replicate it. Some recent digging by users who had the same issue suggested it might somehow be related to Grasshopper loading very large recently used files. Although even then 15GB is a stupendous amount of memory to use, so there may well be more going on here.
Can you erase your MRU list and then immediately restart Rhino + GH? I’d like to know if it still happens. You can wipe the recent files list in the preferences:
Don’t worry, it won’t actually delete the files from the disk, it just makes GH forget about them.
I’ll be out of office for a week starting tomorrow, but I’d like to try and get this fixed once I come back.
Thanks David, clearing the MRU fixed it immediately. I’ve run across some other instances where there are significant performance problems when a recent files list tries to find files that are missing, so on the chance that the missing files were the problem I first tried running the ‘Remove missing files’ button. About 20% of the files dropped off but the problem was still occurring. Removing all of the files solved the problem.
I also tried purging all but the last 5 files since that’s primarily what I’ve been working in since this started happening, and just those 5 didn’t cause a problem. If it’s worth while I can try to keep narrowing down the problem file(s).
I made several changes/fixes the file loading/checking/caching mechanisms and I think it’s fixed. However since I was never able to repeat this problem with the same severity as some of you, I’m not sure if I solved a different minor problem, or the actual problem.
Next week’s Rhino WIP release will feature these changes so I guess we’ll see then.
I think I have the same issue. I tried to delete the MRU list within GH preferences but after a restart of Rhino/GH it reappears with 400ish files. I am running the latest Rhino 5 and Grasshopper.
Any ideas?
There was an additional bug which didn’t update the MRU settings after clearing the lists. In Rhino5, what you need to do is clear the lists and then open or save one file. At this point the persistent MRU lists will be properly updated.
It appears that the update in Rhino WIP seems to have resolved the issue. Rhino 5 isn’t as bad as it was when I started this thread, but with the problem file in the MRU list it still reaches around 2.5GB of memory used and takes about 30 seconds before it settles down enough to actually use it. Rhino WIP doesn’t appear to struggle at all with the file being there and is basically ready to go immediately and only brings my memory usage for Rhino up to about 240MB.