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

Cory Quammen cory.quammen at kitware.com
Fri Jul 10 12:19:29 EDT 2015


Berk,

Yes, that might be possible. The tricky part is that the resize needs to be
done correctly in the various places where the original table size is
modified, of which there are a few
(vtkLookupTable::SetNumberOfTableValues(), ::SetNumberOfColors(),
::SetTable(), etc.). I'll try it out and push a patch when I get the chance.

Best,
Cory



On Wed, Jul 8, 2015 at 2:01 PM, Berk Geveci <berk.geveci at kitware.com> wrote:

> It looks like that code can be refactored to do the resizing in some sort
> of initialization method. This comment:
>
>   // Resize the internal table to hold the special colors at the
>   // end. When this function is called repeatedly with the same size
>   // lookup table, memory reallocation will be done only one the first
>   // call if at all.
>
> indicates that the size does not change dynamically. Maybe it can be
> changed to always allocate for the special colors from the beginning?
>
> -berk
>
> On Wed, Jul 8, 2015 at 2:40 PM, Cory Quammen <cory.quammen at kitware.com>
> wrote:
>
>> Sean,
>>
>> I will take a look.
>>
>> Cory
>>
>> On Wed, Jul 8, 2015 at 1:11 PM, Sean McBride <sean at rogue-research.com>
>> wrote:
>>
>>> 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
>>>
>>>
>>>
>>
>>
>> --
>> Cory Quammen
>> R&D Engineer
>> Kitware, Inc.
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>


-- 
Cory Quammen
R&D Engineer
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150710/baf0aeed/attachment.html>


More information about the vtk-developers mailing list