[Paraview-developers] garbage collection revisited (hijacked thread)

[Biddiscombe, John A.]

Utkarsh - sorry for hijacking this tread. (Well, actually I'm not sorry, but I have to say that out of politeness)

I have some big problems with the garbage collection. The main problem is that it simply isn't needed in 99.9% of the code in vtk/paraview, but unfortunately is used throughout. There are some actor/mapper/renderer places where it is useful, but everywhere else it is a huge waste of resources/time.
I have some structures like a SIL populated with a tree of several thousand objects, it takes minutes to delete (when debugging is enabled for sure) (and construction is slower than necessary). In my own code, I have had to resort to replacing all calls to Delete with FastDelete and never yet had any problem with dangling references or double deletion. I am considering modifying the pv source in places like the SIL to also use fastdelete.

Could we consider Making non garbage collection/deletion the default, and only using it in places where we know circular reference loops are likely?

JB

From: paraview-developers-bounces at paraview.org [mailto:paraview-developers-bounces at paraview.org] On Behalf Of Utkarsh Ayachit
Sent: 03 March 2013 17:21
To: Joshua Murphy
Cc: paraview-developers at paraview.org
Subject: Re: [Paraview-developers] how do I force garbage collection?

Josh,

I am sending you a patch is a separate email. Just to summarize for the list:

- When writing plugins/readers, turn on CMake flag VTK_DEBUG_LEAKS. ParaView will start dumping messages about any VTK objects that are not cleaned up while exiting the application. That helps to catch stray VTK-object references early in the development process.

-  Use vtkNew<> for creating local VTK objects in methods. Developers often forget to call the Delete() before exiting the method esp. when complicated if/else/swicthes are involved.

- Use vtkSmartPointer<> or vtkWeakPointer<> when storing vtkObjects in STL maps/list. Makes memory management a lot easier.

Utkarsh

On Fri, Feb 22, 2013 at 3:27 PM, Utkarsh Ayachit <utkarsh.ayachit at kitware.com<mailto:utkarsh.ayachit at kitware.com>> wrote:
Josh,

VTK/ParaView uses reference counting. So as long as a there's a reference held to any dataobject, Delete() is not going to release it. Barring cycles, a quick way to see if Delete() will result in clearing the object, is to look it it's ReferenceCount member variable before calling Delete(). However if you're passing the data allocated as output from your filters then the reference maybe getting held by the pipeline beyond your control. If you can share the code, I can see if I can explain why the memory may not be getting released.

Utkarsh

On Fri, Feb 22, 2013 at 12:22 PM, Joshua Murphy <Joshua.Murphy at lasp.colorado.edu<mailto:Joshua.Murphy at lasp.colorado.edu>> wrote:
Hello,

I am writing a cache system for my reader, and I am trying to figure out how to force a garbage collection after I dump my cache.

Does anyone know how to force ParaView to collect garbage?  Currently after I purge my cache (I am calling Delete() on all of the objects and destroying the remainder of the cache map) the system memory does not free up... ParaView remains in control of all of the memory for the dumped cache items, and when the new cache is introduced, the memory usage just keeps going up.

I suppose it is possible that I am missing some fundamental understanding of how ParaView and VTK manage memory, so if someone could help that would be great.


Thanks,

Josh

[cid:image001.png at 01CE18C1.85AE9910]
Joshua J. Murphy
Computer Scientist
Laboratory for Atmospheric and Space Physics
University of Colorado, Boulder


_______________________________________________
Paraview-developers mailing list
Paraview-developers at paraview.org<mailto:Paraview-developers at paraview.org>
http://public.kitware.com/mailman/listinfo/paraview-developers


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20130304/74b0a30c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16467 bytes
Desc: image001.png
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20130304/74b0a30c/attachment-0001.png>