Is it possible to port slicer’s existing architecture from single-threaded to multi-threaded?
Most modules and tools in slicer is already multi-threaded.
1 Like
For reference, both VTK and ITK filters are indeed written by leveraging classes like vtkThreadedImageAlgorithm or itk::MultiThreaderBase
For example, the new SurfaceNets feature heavily relies on the threading capabilities. See New surface model generation method: SurfaceNets
1 Like
@muratmaga @jcfr Thank you for your inputs. I appreciate you bringing the references to my attention. However, based on the description of itk::MultiThreaderBase, this class appears to focus on parallelizing image operations.
My current focus is on parallelizing operations on vtkMRMLScene , specifically the SaveSceneToSlicerDataBundleDirectory() function.
There are plans to ultimately switch to Zlib-ng for some performance improvements. See this former thread that might be related to your topic.
1 Like
@MJamal do you know specifically which bottlenecks you are trying to address? As @jamesobutler points out, a lot of the time for loading/saving bit volume datasets if the compression time, which can be avoided with a switch. You probably want to do some profiling to see where time is really being spent before trying to optimize.
For the case where there are a lot of non-volume files in the scene it could make sense to load/save them in parallel.
I did an experiment loading vtk files in parallel that you can look at for reference. It does work, but would need to be generalized to save and load and work on more node types to be generally useful. A lot of the performance implications depend on whether the files are local or remote, how big they are, how much processing is needed for each file type, etc.
1 Like
I need some time to discuss the bottlenecks here. I’ll also look into the references provided above and update you soon. Thanks 