eleFront and Memory Management
Last updated
Last updated
Many of the new features in eleFront are oriented around reducing the overall amount of memory being used in a given Rhino session.
If there is not enough free memory, all computations slow down as the computer tries to manage moving data around for each part of the solution. This can cause solve times to increase, regardless of the actual complexity of the computation. Even using multithreading cannot compensate for a scenario where there is not enough spare memory to support the computation.
Consider the graphs below.
The "traditional" way of working with eleFront, which consists of loading some reference geometry into Rhino via a worksession, then into Grasshopper via eleFront, you can see the memory usage below:
As you can see, the geometry is loaded into memory the first time, when it is attached to the Rhino document, and then another copy is created as Grasshopper geometry.
If you don't actually need the geometry to be available in the Rhino document, and you only want to operate on it from within Grasshopper, you can skip loading, thus only creating one copy of the geometry:
If you simply need to move objects around, or if you only need the geometry from a subset of the overall model, you can use the Ghost Geometry features to only load in a placeholder for the objects, that still maintains the attributes.
As you can see, this brings the memory footprint from 11 GB to 2.0 GB, and that's before doing any further operations in Grasshopper. Of course, if you need to operate on all of the geometry, this may not be the right approach. However, if you only needed, for example 10% of the objects, you could use Ghost Geometry to filter down to the items you need, then Manifest that 10%, and keep your total memory overhead to a minimum.
