I was playing with a very simple C# script and my system ran out of memory. At the time, I was randomly creating/renaming variables trying to get the C# syntax correct (new to Rhino/C#). It did not have a non-ending loop. I’ve condensed this to test-code. This seems to be a memory deallocation issue. See the video.
memory_problems.gh (10.6 KB)
1 Like
Well … you got it rather wrong. But I’'m not in the practice right now (where various GC examples are available).
In the mean time read this classic:
I wouldn’t be surprised if I have it incorrect (new). I’m familiar with memory management, although that is an excellent read for explaining it. I didn’t see any examples that implemented any memory management in the Grasshopper/C# examples and tutorials so I thought it was being handled by the Grasshopper engine. Please post an example for Rhino/Grasshopper when you can. I’d certainly appreciate it. Thank you!
Note: GC (as it is) does a reasonably good job. No need to botther unless you want to find the truth out there (there’s none around).
Anyway get an entry level take (pointless to the max).
GC_V1.gh (129.2 KB)
Tip: better get a proper Ducati (and sell the Prius)
Thank you!
BTW: As I said, I strongly recommend to leave GC to do his thing. But … there’s rare cases where manual calls to GC.Collect() are MAYBE required. Like working with large objects that are wrapped in tiny managed objects, which in turn are accessed from C#.
The GC never get called because the amount of managed memory in most of real life cases is negligible, but the amount of unmanaged memory used MAY be big/huge. Manually calling Dispose() on the objects would require tracking of when objects are no longer needed, whereas calling GC.Collect() will clean up any objects that are no longer referred…
PS: Changed some things: demo graph was ultra stupid (via that Math.Log thing: a classic Remap is the way to go).
GC_V1A.gh (136.2 KB)
Moral: Ducati Uber Alles