[vtk-developers] Major performance regression in VTK 6.2 to 6.3 with vtkLookupTableMapData().
Sean McBride
sean at rogue-research.com
Wed Jul 8 14:11:11 EDT 2015
Hi all,
As a mentioned in another thread, we've found a big slowdown in our app between 6.2 and 6.3. Profiling with Instruments reveals lots of time is being spent locking & unlocking a mutex in vtkLookupTableMapData(). Looking through git history shows the culprit:
----------------------------
commit dac748aedd7ffdc5aca6d555e74c668451ef4772
Author: Cory Quammen <cory.quammen at kitware.com>
Date: Sun Mar 15 00:33:11 2015 -0400
BUG 15365: Fixed crash in function called from multiple threads
vtkLookupTableMapData() was not thread safe and could lead to
crashes when accessed from multiple threads. Added a mutex around
the logic to determine if the color table size needed to be
increased.
Added a multi-threaded test that crashes on occasion prior
to this patch, but does not crash with this patch applied.
----------------------------
Indeed the added code has the comment:
// Since this involves a potential array resize and this function
// might be accessed concurently from more than one thread, we need a
// mutex here. This shouldn't affect performance much if this function
// is used to map many input values, but if it is called repeatedly
// with short input arrays, performance may be much worse.
So, for my use case, performance is indeed much worse. :(
As a hack, I removed the lock/unlock and performance is back to 6.2-level.
Help? :)
--
____________________________________________________________
Sean McBride, B. Eng sean at rogue-research.com
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
More information about the vtk-developers
mailing list