[vtk-developers] Performance tuning

[John Platt]

I am not familiar the VTK 5 pipeline mechanism changes so perhaps
someone could explain the implications on replacing or deleting a local
section of a pipeline with little knowledge of the downstream filters.

Take for example, switching shrink on or off. This probably involves
inserting or deleting a shrink filter and possibly switching between
vtkShrinkPolyData or vtkShrinkFilter.

If the VTK 5 mechanism does not allow the shrink filter to be destroyed
because it is somehow referenced by a downstream filter, I've got
problems.

In VTK 4.4, my understanding is that just the filter output is
registered by the next downstream filter and
UnRegisterAllOutputs()allows the filter to be destroyed.

I would sooner be bitten by bad pointers rather than have orphaned
filters consuming memory.

As a side point, in VTK 4.4 at least, it would have been nice if
vtkObjectBase::Delete()returned the reference count rather than a void.
This would make it very easy to check if an object had actually been
destroyed.

John Platt.

 

-----Original Message-----
From: vtk-developers-bounces+jcplatt=lineone.net at vtk.org
[mailto:vtk-developers-bounces+jcplatt=lineone.net at vtk.org] On Behalf Of
Ken Martin
Sent: 27 June 2005 13:52
To: 'VTK Developers'
Subject: [vtk-developers] Performance tuning

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