[vtk-developers] vtkAbstractTransform and thread safety

David Gobbi david.gobbi at gmail.com
Wed May 29 16:57:43 EDT 2013


I agree that the critical sections are probably not necessary.  But
instead of removing them completely, it might be best to add a
boolean method to specify whether they are to be used.

I suspect that another thing that is slowing down vtkGlyph3D and
many other algorithms is the fact that vtkDataArray::GetTuple(),
and therefore vtkPoints::GetPoints() which uses it, involves a
virtual method call.  For hot code paths like
vtkLinearTransform::TransformPoints() as defined in
vtkLinearTransform.cxx, a SafeDownCast to vtkFloatArray or
vtkDoubleArray would allow the use of the inlined GetTupleValue()
and SetTupleValue() methods.

 - David

On Wed, May 29, 2013 at 1:58 PM, David Lonie <david.lonie at kitware.com> wrote:
> Hi David,
>
> I noticed in the vtkAbstractTransform class that there are a set of mutexes
> that guard the Update() and GetInverse() methods. Are these necessary? They
> were introduced in this commit:
>
> commit 793c003c5064ff90bfee3769d6b85cc4c75104f6
> Author: David Gobbi <david.gobbi at gmail.com>
> Date:   Wed May 3 16:53:37 2000 -0400
>
>     ERR: The way that GetInverse worked, there was no easy way to fix the
>          existing memory leak.  So the GetInverse mechanism has changed (and
>          is more efficient than it used to be) but significant other changes
>          were necessary.
>
>
> I'm looking at the performance of some filters, and vtkGlyph3D makes heavy
> use of the transform classes to position/scale the glyphs before copying
> them into the output. Trouble is, each new transform dynamically allocates
> two mutexes, and building up the transforms requires entering critical
> sections. Benchmarking Glyph3D shows that removing these mutexes cuts out
> about 10% off of the time it takes the filter to update. I imagine this
> overhead is hurting performance in other instances, too.
>
> Since VTK isn't typically thread-safe and most uses of the transforms (that
> I'm aware of) are single-threaded, it seems reasonable to me that these
> should be removed. Is there any reason to keep them?
>
> Thanks,
> Dave



More information about the vtk-developers mailing list