[vtk-developers] Performance tuning

[Will Schroeder]

FYI- This may be irrelevant, but ITK uses the weak reference approach #2 below.
Will

At 08:51 AM 6/27/2005, Ken Martin wrote:
>I've been doing some performance tuning in prep for VTK 5.0 and there is an
>issue I'd like to discuss. One of the changes in VTK CVS that wasn't in VTK
>44 is that the pipeline now holds reference counts going upstream and
>downstream. If you have a reference to the source of a pipeline the entire
>pipeline will be held. In VTK 4.4 the pipeline only held references going
>upstream (although there were pointers going downstream as well). So in VTK
>4.4 if you held a reference to a source then the source would stay around
>but the rest of the downstream pipeline could be freed. So here is the deal,
>having full reference counting upstream and downstream creates a lot of work
>for the garbage collector in some cases, these performance bottlenecks can
>be worked around using the Deferred collection and FastDelete methods but
>that requires some knowledge and smarts on the developer's part. The
>alternative is to go back to VTK 4.4 style single connected pipeline that
>has a weak downstream reference. In most cases that speeds up the GC
>significantly (because the reference graphs are much smaller). So here's the
>summarized question, which would you prefer?
>
>1) Developers must be smart about GC but the pipeline will be a doubly
>linked list with strong references
>
>2) The Developer can be more ignorant about GC but might be bitten by the
>weak downstream reference in the pipeline
>
>Currently 1) is what we have in CVS and 2) is what is in VTK 4.4 and
>earlier. Note, in either case we will still be using the GC, the main
>performance problem has been that the doubly linked list has created far
>larger GC networks that VTK 4.4 ever had to deal with.
>
>Thanks
>Ken
>
>
>_______________________________________________
>vtk-developers mailing list
>vtk-developers at vtk.org
>http://www.vtk.org/mailman/listinfo/vtk-developers