[vtk-developers] Major performance regression in VTK 6.2 to 6.3 with vtkLookupTableMapData().

[Sean McBride]

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