Grasshopper

algorithmic modeling for Rhino

I was scripting many components in the VB Script editor, and I have recently faced with some out of memory warnings, prompted me to look into more details about the custom script.

I am passing my custom created objects out from one script components to another one. In order for me to make changes to the object in subsequent script without contaminating the object memory, I made a duplicate of the object whenever it is passed into a script, I edit the duplicate and pass that duplicate out.  This method was probably suggested by David a year ago when he responded to some of my question asking what happens when a data is passed out of a component to another one. He mentioned that the data is cloned to a new memory location by default.

The scale I'm working with is that in each object I have three dictionary of (String, Object). Each containing 10+ values of various points, curves and strings. I have 500-1000 objects passing through about 10 subsequent scripts for manipulation.

I start to wonder if this is a bad way of scripting particularly I don't understand how garbage collection is managed for such objects on the canvas. For example if part of the script is updated because it detected a input change, how are the outdated object going out of reference and eventually being collected.

Another question is if the duplication is created this way (simplified code):

Is it true that I've coded it in a way such that the dictionary will go out of reference when the object itself go out of reference.

Cheers - Thanks a lot

Victor

Views: 538

Replies to This Discussion

Hi Victor,

The amount of memory used will primarily depend on the length of the strings and the type of object in your Geometries dictionary. A single string can take up a lot of space, but most strings are quite small. A Geometry instance may also contain many bytes, especially if you're dealing with complicated Breps that have high-quality meshes embedded.

Incidentally, New Dictionary(Of String, Object)(Geometries) does not make a copy of the geometry data. It will create a new dictionary that points to the same data. Only value types will be duplicated in this way.

Although it is certainly possible to run out of memory, this typically is not the fault of the Garbage Collector. The GC will start reclaiming unused memory whenever it feels it pays to do so. A high memory consumption would be such a scenario. If you memory consumption goes up and up it is more likely that data is somehow prevented from being collected or maybe memory is leaking.

I can't investigate this at the moment due to time limits, but you'll have to post your code eventually of someone is going to have a close look at what might be causing the memory increase.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Hi David, thanks for your reply and the note on the New Dictionary(Of String, Object)(Geometries)

Don't worry about investigating on this at the moment. My company is switching to Rhino 5 soon, and hopefully may solve the problem.

However, is it true that every time a solution recalculates, the data in the script should go out of reference.

Cheers

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service