[vtkusers] Performance issue with vtkAssembly::UpdatePaths

Andrew Cunningham andrewc at mac.com
Thu May 14 12:29:08 EDT 2009


There is, I think , a serious o(n!) (factorial) problem with the vtkAssembly::UpdatePaths code.


The problem is
1) vtkAssembly::GetMTime()  recursively descends through the "scene graph" touching all nodes
2)  vtkAssemblyPath::GetMTime() runs through all it's items (some of which will be  vtkAssembly's ) and calls GetMTime()  on each item

So for example, if you have a vtkAssembly:: tree that is with various mixtures of vtkAssembly's  and vtkActors.

Firstly, the call this->GetMTime() causes a recursive transversal of the graph starting at 'this', calling GetMTime() on every node. This is o(n).

Then, this->Paths->GetMTime() , is called. This iterates through each node of the vtkAssemblyPath calling GetMTime(). Each time it encounters a node that is a  vtkAssembly, then it will trigger a recursive traversal starting at that node. The number of calls to GetMTime will be on the order of n!

If you have a complex scene graph, this can actually  become a huge bottleneck.


Here is the code snippet.

// Build the assembly paths if necessary. UpdatePaths()
// is only called when the assembly is at the root
// of the hierarchy; otherwise UpdatePaths() is called.
void vtkAssembly::UpdatePaths()
{
  if ( this->GetMTime() > this->PathTime ||
    (this->Paths != NULL && this->Paths->GetMTime() > this->PathTime) )
    {
....


Andrew



More information about the vtkusers mailing list