[vtk-developers] Better than O(n) prop operations on vtkRenderer

[Andras Lasso]

We do this very similarly in 3D Slicer, too: we very rarely iterate through VTK collections but we use STL maps, deques, sets, etc. to keep track of groups of VTK objects.

There is no need to hypothesize about what performance degradation collections may cause because we can find performance bottlenecks much more efficiently by profiling.

What I usually see on Windows is that polydata algorithms tends to spend a lot of time (few ten percent) doing elementary data access operations, such as getting and setting point coordinates. So, some tricks to speed that up could make a difference. The abstraction layer that was added to allow storing data using arbitrary memory layout seemed to decrease performance, too (by about 5-10%). While visualizing image slices  of volumes using OpenGL2 backend + Qt5 appears to be slowed down by some OpenGL texture operations, which results in 10-20% lower refresh rates compared to the old OpenGL backend. Has anyone else found these same performance bottlenecks while profiling VTK-based applications?

Andras

________________________________
From: Todd Martin via vtk-developers <vtk-developers at public.kitware.com>
Sent: Thursday, December 13, 2018 6:19 PM
To: Elvis Stansvik; David Gobbi
Cc: VTK Developers
Subject: Re: [vtk-developers] Better than O(n) prop operations on vtkRenderer

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.



Todd Martin, PhD.
Freelance Engineer/Software Architect.



On Friday, 14 December 2018, 12:06:59 PM NZDT, David Gobbi <david.gobbi at gmail.com> wrote:


Hi Elvis,

I don't think there are any fans of vtkCollection, but replacing it
with something modern would be lot of work and would provide
far less benefit than e.g. the recent reworking of the VTK data
arrays to provide flexible memory access patterns.

Also, given the cost for vtkRenderer to render a bunch of props,
you would have to be doing many hundreds (thousands?) of
insertions/removals per render before the time required for those
operations becomes significant to overall app performance.

  David


On Thu, Dec 13, 2018 at 3:33 PM Elvis Stansvik <elvis.stansvik at orexplore.com<mailto:elvis.stansvik at orexplore.com>> wrote:
Hi all,

The props of a vtkRenderer are kept in a vtkCollection (and probably
have been since VTKs childhood), meaning linear time
search/insert/remove.

I realize the use of vtkCollection is pervasive in these classes, and
also shines through in their API, so this is a bit of a long shot,
but, is there any chance that it'll at some point be converted to use
a sorted data structure, to permit logarithmic operations?

Has anyone else had the need to rapidly insert/remove/check for props
in a renderer with a large amounts of props in it? Has the idea of
having vtkRenderer backed by something else been discussed before?

Cheers,
Elvis
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C61d78fa19d324baf82eb08d661517616%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636803399838921389&sdata=3o5i7hDrznYn3%2FNCY5pUNpLuW7xzF4x2A0giA6Vq72U%3D&reserved=0>

Search the list archives at: http://markmail.org/search/?q=vtk-developers<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C61d78fa19d324baf82eb08d661517616%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636803399838921389&sdata=vAxn%2BGTmCoOhD1X0oSuSEGuYI6F5J7faOb%2B5m3JWdmo%3D&reserved=0>

Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/vtk-developers<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C61d78fa19d324baf82eb08d661517616%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636803399838931389&sdata=2Xf3v7M4Szs4q%2BjbtTxvB4%2Fihx6u%2F9wNiiYpKPwub74%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20181214/4cea2944/attachment-0001.html>