Slicer interactions would benefit from using a BST instead of linear search

Development
1

I would like to make the argument that functions like vtkSlicerMarkupsWidget::ProcessInteractionEvent could be the reason of bottleneck performance around 100 fiducial points.

Because it has a switch stament with 21 cases:

According to math we could get interaction 4 times faster if we used binary search on a Binary Search Tree for the function callbacks instead of switch staments if it was only for this different algorithms complexity.

Also I found this classes to have to more than 6 or 8 case staments:

vtkMRMLSubjectHierarchyNode::ItemEventCallback
vtkMRMLAbstractThreeDViewDisplayableManager::PassThroughInteractorStyleEvent
vtkMRMLCameraWidget::ProcessInteractionEvent
vtkMRMLSliceIntersectionWidget::ProcessInteractionEvent
vtkMRMLWindowLevelWidget::ProcessInteractionEvent
vtkMRMLAbstractLogic::ProcessMRMLSceneEvents
qMRMLSceneModel::onMRMLSceneEvent
void ITKComputeThresholdFromVTKImage
vtkDiffusionTensorGlyph::RequestData
static void vtkDiffusionTensorMathematicsExecute1Eigen
void vtkDiffusionTensorMathematics::ThreadedRequestData
itk_data_types
vtkAnnotationGlyphSource2D::RequestData
vtkMarkupsGlyphSource2D::RequestData
qMRMLSegmentsModel::onEvent
qMRMLSubjectHierarchyModel::onEvent

I would know how to solve this is python with lambdas but I don’t know how to do it in C++.

Comments are welcomed

2

Hi @mau_igna_06 it would definitely be good to make the markups interactions more scalable to handle more points and other entities. I’m skeptical that the switch statement itself is the performance bottleneck since the compiler will make those pretty efficient. But to be sure I suggest you consider using a performance analysis tool. People have had good luck with VerySleepy on windows, or similar tools on other platforms. Once we know exactly where the time is being spent we can talk about options for improving the implementations.

2 Likes