<div dir="ltr">Berk,<div><br></div><div>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.</div><div><br></div><div>Best,</div><div>Cory</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 8, 2015 at 2:01 PM, Berk Geveci <span dir="ltr"><<a href="mailto:berk.geveci@kitware.com" target="_blank">berk.geveci@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It looks like that code can be refactored to do the resizing in some sort of initialization method. This comment:<div><br></div><div><div>  // Resize the internal table to hold the special colors at the</div><div>  // end. When this function is called repeatedly with the same size</div><div>  // lookup table, memory reallocation will be done only one the first</div><div>  // call if at all.</div></div><div><br></div><div>indicates that the size does not change dynamically. Maybe it can be changed to always allocate for the special colors from the beginning?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-berk</div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Jul 8, 2015 at 2:40 PM, Cory Quammen <span dir="ltr"><<a href="mailto:cory.quammen@kitware.com" target="_blank">cory.quammen@kitware.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Sean,<div><br></div><div>I will take a look.</div><div><br></div><div>Cory</div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Wed, Jul 8, 2015 at 1:11 PM, Sean McBride <span dir="ltr"><<a href="mailto:sean@rogue-research.com" target="_blank">sean@rogue-research.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
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:<br>
<br>
----------------------------<br>
commit dac748aedd7ffdc5aca6d555e74c668451ef4772<br>
Author: Cory Quammen <<a href="mailto:cory.quammen@kitware.com" target="_blank">cory.quammen@kitware.com</a>><br>
Date:   Sun Mar 15 00:33:11 2015 -0400<br>
<br>
    BUG 15365: Fixed crash in function called from multiple threads<br>
<br>
    vtkLookupTableMapData() was not thread safe and could lead to<br>
    crashes when accessed from multiple threads. Added a mutex around<br>
    the logic to determine if the color table size needed to be<br>
    increased.<br>
<br>
    Added a multi-threaded test that crashes on occasion prior<br>
    to this patch, but does not crash with this patch applied.<br>
----------------------------<br>
<br>
Indeed the added code has the comment:<br>
<br>
// Since this involves a potential array resize and this function<br>
// might be accessed concurently from more than one thread, we need a<br>
// mutex here. This shouldn't affect performance much if this function<br>
// is used to map many input values, but if it is called repeatedly<br>
// with short input arrays, performance may be much worse.<br>
<br>
So, for my use case, performance is indeed much worse.  :(<br>
<br>
As a hack, I removed the lock/unlock and performance is back to 6.2-level.<br>
<br>
Help? :)<br>
<span><font color="#888888"><br>
--<br>
____________________________________________________________<br>
Sean McBride, B. Eng                 <a href="mailto:sean@rogue-research.com" target="_blank">sean@rogue-research.com</a><br>
Rogue Research                        <a href="http://www.rogue-research.com" rel="noreferrer" target="_blank">www.rogue-research.com</a><br>
Mac Software Developer              Montréal, Québec, Canada<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div>Cory Quammen<br>R&D Engineer<br>Kitware, Inc.</div>
</font></span></div>
<br></div></div><span class="">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
<br></span></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Cory Quammen<br>R&D Engineer<br>Kitware, Inc.</div>
</div>