Rhino memory management

(Menno Deij - van Rijswijk) #1

I have a question about how Rhino manages its memory. I am working on batch grid generation for CFD, generating many meshes sequentially.

To prevent having to keep everything in memory, I run the algorithm as follows.
I have a large set of 3dm files that each contain a different set of surfaces for which a grid must be generated. At every iteration of the algorithm a file is opened, its geometry is read, a grid is generated and written to the file, after which it is closed.

I do find, however, during profiling of this algorithm that the memory footprint of Rhino increases to levels above 2 Gb (by looking in Task Manager to Memory/Private Working Set). Sporadically, however, it suddenly drops to “normal” levels, of let’s say 150 Mb.

My question is: is this expected behavior? Especially the sudden drop? Is that some sort of intermittent memory free operation in Rhino?

Note that I do not refer to .NET memory management. No matter how often I call GC.Collect() the memory footprint is not affected by this. Also, using CLR profiler I find that the .NET part of the memory use is constantly in the order of 100 Mb.

Memory leak from .NET plug-in

Those are good questions. Could the sudden drops be related to any timed action (e.g. autosave, etc)?

(Steve Baer) #3

I wonder if there is geometry getting placed on the undo stack. Are you adding geometry to the Rhino document? Maybe try calling ClearUndoRecords.

(Menno Deij - van Rijswijk) #4

No, i’m only reading data using file3dm.read, create many intermediate geometry objects, then write the final result to 3dm.