I’m experiencing a weird behavior in a custom component that I’ve been developing. Depending on how I execute the component, the usage of memory remains stable or starts increasing inexplicably.
When the component is executed right after orbiting/panning/zooming in the Rhino viewport, the memory usage increases and the performance gets worse (takes longer to solve).
When the component is executed after panning/zooming in the Grasshopper canvas, the memory usage remains stable.
In both cases the inputs are the same. I think that the problem is related to the position of focus or to the active control when the component starts running.
Do you have any idea about what is happening and how to fix it?
Thank you in advance!
If you are doing custom display on your component or parameters, the problem is there. It sounds like not caching the display mesh and building it every time Rhino draws the scene.
Why you think that? You will need to provide more information so that someone can help you.
Thanks you for your answer Dani! I’ve disabled the preview of the custom GooParameter that I’m using and didn’t work. I have also removed the custom classes from input and output to discard interactions with the custom preview. The problem still there.
I think that because of the behavior that I’m observing. If I pan the canvas before running the component, it runs smoothly. My hypothesis is that I’m triggering some event when I pan the GH canvas that is “cleaning” the relationship with the viewport.
Well I have solved it by changing a method that was using Line (struct) and intersection. Now I use a LineCurve and force the memory release. Seems that the garbage collector had problems removing them … but not always, just when running the command after orbiting in a Rhino viewport (please take a look, seems like a bug to me).