Grasshopper interface freezes and it uses large amount of memory during start

this is a continued discussion on the issue reported in a previous post:

http://www.grasshopper3d.com/forum/topics/grasshopper-consumes-huge...

First of all, the invalid Rhino license as seen previously has been removed, and the correct educational license we have is re-installed for this test.

The re-appearing issue is that RAM usage spikes once GH is open in Rhino. It seems that this happens when a series of large GH project files incrementally saved are stored in the same folder. Moving those previously saved large project files to a new folder seems to be able to solve this issue.

The images below explains the issue and the hypothetical solution:

1. A series of GH files were incrementally saved in the same folder previously, and the last few GH files are the ones opened most recently:

2. The total RAM usage is at the normal 5GB level once Rhino is open:

3. Once GH is open, the RAM usage spikes, and the it becomes very slow to maneuver the GH window before even opening any one of those GH files:

4. Once GH and Rhino are closed, the RAM usage drop to the previous level before the GH interface was open:

5. Now, all the incrementally saved GH files are moved to a new folder "wip" except the last one, i.e. for the last GH file, there is no other previous GH files in the same location:

6. Now, if we open GH, there is no sudden increase of RAM usage, and the 3x3 thumbnails on the GH canvas shows "missing" as those previously opened GH files are no longer in the same location as they were before:

I understand that David mentioned that the thumbnails for previously opened GH files on GH canvas will not take much RAM. Nevertheless, I'm still not sure what is causing the increase of RAM usage and slowdown of GH interface. Relocating the large project files previously saved in the same folder as the current GH file seems to be able to make this issue go away, for unknown reason ...

Appreciate if anybody experiencing similar issue can help to check if this solution works.

Thank you.

Replies to This Discussion

Permalink Reply by Grasshope on January 26, 2017 at 2:06am

Thanks, Tom. Will try your suggestion.

Permalink Reply by David Rutten on January 26, 2017 at 3:37am

Great observation. So it's probably related to either the MRU server, the MRU menu timeline or the MRU canvas tiles. That narrows down the search significantly.

ps. 5GB for vanilla Rhino!? Mine takes up 350 MB...

Permalink Reply by Grasshope on January 28, 2017 at 11:10pm

Thanks, David.

I searched "MRU server", and it seems it is a bit difficult for me to follow. Can you kindly share a bit more in this regard?

Is there any more test we can do to trace the issue?

P.S. The 5GB RAM was the memory level when several other applications were open at the same time. I should probably close irrelevant applications when using Rhino next time so as to fully enjoy its rosy aroma ... :)

Permalink Reply by David Rutten on January 29, 2017 at 3:01am

The MRU server is the bit of code which keeps track of which files have been recently used (MRU stands for 'Most Recently Used'). It knows when a file was last accessed, it knows how to check whether that file still exists and it knows how to extract the thumbnail image. It's the latter operation which now worries me, because gh files are fully compressed meaning they need to be read in their entirety, decompressed and the image extracted. If the file data is then not properly released, it may stick around in memory.

RSS