[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