<div dir="ltr"><div>I didn't bother with the benchmarks, the improvement was so significant for my situation, it went from 5-10 seconds down to milliseconds for some operations.</div><div><br></div><div>I was adding hundreds or thousands of polydata actors (one per 3d model loaded from files),</div><div>and there were a few situations where VTK would to search the collection looking for a particular actor.</div><div><br></div><div>I recall that ::Remove() (or similar) was used in RemoveAll() ? Or destruction? I can't quite remember.</div><div>There were a couple of other places where it would iterate through the list looking for a particular actor.<br></div><div>I think during destruction was a problem for me for this reason.</div><div>So it was effectively O(n^2) for a RemoveAll() operation.<br></div><div><br></div><div>eg If the list of actors / model files changed, I would need to remove lots of actors and add new actors to match the new files.</div><div>If the file list changed significantly, it would take a long long time just because of the actor removal.</div><div>If the user ticked off a whole folder of files, it might cause the GUI to pause for multiple seconds.</div><div>Significant enough that it became a road block and I had to spend some time on the problem.<br></div><div><br></div><div>Perhaps I could've structured it differently by putting all the polydata into one actor,</div><div>but as its implemented it works very quickly - no need to recompute polygons and vertices just to switch off an actor/model from the list of models.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 14 Dec 2018 at 08:09, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com">bill.lorensen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Do you have benchmarks that show the differences? </div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 13, 2018, 3:47 PM Paul Harris <<a href="mailto:harris.pc@gmail.com" target="_blank">harris.pc@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I had to hack vtkCollection for this exact reason.</div><div><br></div><div>It keeps an ordered linked list because its design allows for the same element to be added multiple times.</div><div><br></div><div>I replaced that ordered linked list with a boost::multi_index, so it kept the old interface, multiple-entry feature, and addition-order,</div><div>but also added fast lookups and fast removal.</div><div><br></div><div>I'm happy to share the code. It was hacked into an older VTK version, and added a boost dependency, so it'll need some cleanup in that respect. But I did check the newer VTK code when I hacked it in July and it didn't look like it had changed much. So apart from the boost dependency, it might be easy to bring into the latest VTK.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 14 Dec 2018 at 07:19, Todd Martin via vtk-developers <<a href="mailto:vtk-developers@public.kitware.com" rel="noreferrer" target="_blank">vtk-developers@public.kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-m_-8182002517278566084m_6442459701352712924gmail-m_-116113210251253409gmail-m_-2982043095362419417ydp75171053yahoo-style-wrap" style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:16px"><div><div>My solution to this kind of problem in the past has been to build a (non-clustered) sorted index for fast lookup on the collection, without changing the underlying collection itself. In fact multiple indicies could be built and (if desired) attached to the collection in a list. Of course it means that each index needs to be rebuilt, when anything is added to or removed from the collection. The most efficient way to do that is to set a flag when anything changes and then only rebuild the index the next time it is accessed.<br></div><div><br></div><div><br></div><div><br></div><div class="gmail-m_-8182002517278566084m_6442459701352712924gmail-m_-116113210251253409gmail-m_-2982043095362419417ydp75171053signature"><div style="font-size:16px;font-family:Helvetica,Arial,sans-serif"><div>Todd Martin, PhD.<br></div><div><i>Freelance Engineer/Software Architect.</i></div><br></div></div></div>
<div><br></div><div><br></div>
</div><div id="gmail-m_-8182002517278566084m_6442459701352712924gmail-m_-116113210251253409gmail-m_-2982043095362419417yahoo_quoted_5635360879" class="gmail-m_-8182002517278566084m_6442459701352712924gmail-m_-116113210251253409gmail-m_-2982043095362419417yahoo_quoted">
<div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px;color:rgb(38,40,42)">
<div>
On Friday, 14 December 2018, 12:06:59 PM NZDT, David Gobbi <<a href="mailto:david.gobbi@gmail.com" rel="noreferrer" target="_blank">david.gobbi@gmail.com</a>> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="gmail-m_-8182002517278566084m_6442459701352712924gmail-m_-116113210251253409gmail-m_-2982043095362419417yiv7840540130"><div><div dir="ltr">Hi Elvis,<div><br clear="none"></div><div>I don't think there are any fans of vtkCollection, but replacing it</div><div>with something modern would be lot of work and would provide</div><div>far less benefit than e.g. the recent reworking of the VTK data</div><div>arrays to provide flexible memory access patterns.</div><div><br clear="none"></div><div>Also, given the cost for vtkRenderer to render a bunch of props,</div><div>you would have to be doing many hundreds (thousands?) of</div><div>insertions/removals per render before the time required for those</div><div>operations becomes significant to overall app performance.</div><div><br clear="none"></div><div> David</div><div><br clear="none"></div><div><br clear="none"><div class="gmail-m_-8182002517278566084m_6442459701352712924gmail-m_-116113210251253409gmail-m_-2982043095362419417yiv7840540130gmail_quote"><div class="gmail-m_-8182002517278566084m_6442459701352712924gmail-m_-116113210251253409gmail-m_-2982043095362419417yiv7840540130yqt6418243541" id="gmail-m_-8182002517278566084m_6442459701352712924gmail-m_-116113210251253409gmail-m_-2982043095362419417yiv7840540130yqtfd14644"><div dir="ltr">On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik <<a rel="nofollow noreferrer" shape="rect" href="mailto:elvis.stansvik@orexplore.com" target="_blank">elvis.stansvik@orexplore.com</a>> wrote:<br clear="none"></div><blockquote class="gmail-m_-8182002517278566084m_6442459701352712924gmail-m_-116113210251253409gmail-m_-2982043095362419417yiv7840540130gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br clear="none">
<br clear="none">
The props of a vtkRenderer are kept in a vtkCollection (and probably<br clear="none">
have been since VTKs childhood), meaning linear time<br clear="none">
search/insert/remove.<br clear="none">
<br clear="none">
I realize the use of vtkCollection is pervasive in these classes, and<br clear="none">
also shines through in their API, so this is a bit of a long shot,<br clear="none">
but, is there any chance that it'll at some point be converted to use<br clear="none">
a sorted data structure, to permit logarithmic operations?<br clear="none">
<br clear="none">
Has anyone else had the need to rapidly insert/remove/check for props<br clear="none">
in a renderer with a large amounts of props in it? Has the idea of<br clear="none">
having vtkRenderer backed by something else been discussed before?<br clear="none">
<br clear="none">
Cheers,<br clear="none">
Elvis<br clear="none">
</blockquote></div></div></div></div></div></div><div class="gmail-m_-8182002517278566084m_6442459701352712924gmail-m_-116113210251253409gmail-m_-2982043095362419417yqt6418243541" id="gmail-m_-8182002517278566084m_6442459701352712924gmail-m_-116113210251253409gmail-m_-2982043095362419417yqtfd79468">_______________________________________________<br clear="none">Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br clear="none"><br clear="none">Visit other Kitware open-source projects at <a shape="rect" href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br clear="none"><br clear="none">Search the list archives at: <a shape="rect" href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br clear="none"><br clear="none">Follow this link to subscribe/unsubscribe:<br clear="none"><a shape="rect" href="https://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">https://public.kitware.com/mailman/listinfo/vtk-developers</a><br clear="none"><br clear="none"></div></div>
</div>
</div></div>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer 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 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 noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer noreferrer" target="_blank">https://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
</blockquote></div>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer 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 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 noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer noreferrer" target="_blank">https://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
</blockquote></div>
</blockquote></div>