Hello,
we keep running into the problem that computers running our grasshopper definitions run out of memory without an obvious reason.
The script will runand fluctuate between 5 and 12Gb of memory usage for days until the memory footprint increases dramatically (up to 30Gb) and Rhino freezes.
Usually this only happens when multiple scripts are open simoultaneously.
This happens both on windows and mac.
What options are there to profile memory usage of Grasshopper and Rhino? What components or logic patterns are known to use a lot of memory?
Unfortunately I cant share the script due to IP. I have not been able to reproduce this in a simpler script.
Some more info:
There is very little surface geometry in this file.
We are creating positions for industrial robots.
Almost all operations are done on Numbers, Points and Planes.
This does not seem to be related to the “recent file list” memory issue that gets talked about in other threads. This only happens when certain files are open and have ben solved, when opening the files with a disabled solver the memory does not increase as drastically.
Thank you for the hint, but there dont seem to be any errors that create excessive amount of geometries themself.
The heaviest component that is run multiple times is probably some closest point calculations that get the closest points in point clouds of around 10_000 points. This results in 150_000 points in a tree.
However, 150_000 points dont seem to be the reason for 20Gb of memory.
A big problem in figuring out the reason for the memory issue is that the memory doesnt decrease immediately after disabling components and groups. sometimes it takes a few minutes until the memory load decreases after disabling large parts of the definition. This may however be an issue with my computer being at the limit of its RAM.
150K points is a lot Each component they pass through makes a copy, eh? All the more risk that one erroneous graft could result in millions of points. If the points are used to create other geometry, memory use could be very high indeed.
A classical source of memory leaks in .Net applications (managed memory) are static collections or the usage of objects which implement the IDisposable interface, which can’t be freed by the garbage collector. Both are easy to introduce by inexperienced and even advanced programmers. Its even worse because many don’t expect a managed language to create such problems. Usually memory leaks are not easy to spot due to the large amount of RAM, but very long runtimes with lots of data can show them. It could be anything but I would claim its rather custom code because Rhino/Gh are mature. Foremost are you writing code? And when you use 3rd party plugins can you reproduce it without them?
Although points are structs(=value types) and are always copied, a collection of points is passed by reference in compiled components. In script components this is different, because for safety reasons anything is copied. Other than that, if the point is running out of scope the garbage collector kicks in. It could be a problem if you pass something from script component to other script components, when you for some reason keep the script instance alive. Maybe through weird eventhandling, but I would think its rather unlikely. But sure if your datatree is messed up you increase the data by a couple of magnitudes or more with ease!
Each component they pass through makes a copy, eh? All the more risk that one erroneous graft could result in millions of points. If the points are used to create other geometry, memory use could be very high indeed.