# Slicer's existing architecture

**URL:** <https://discourse.slicer.org/t/slicers-existing-architecture/34732>\
**Category:** Development\
**Created:** [March 6, 2024, 4:35am UTC](https://discourse.slicer.org/t/slicers-existing-architecture/34732 "2024-03-06T04:35:17Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![MJamal](https://avatars.discourse-cdn.com/v4/letter/m/d26b3c/32.png) [@MJamal](https://discourse.slicer.org/u/MJamal)\
**Post date:** [March 6, 2024, 4:35am UTC](https://discourse.slicer.org/t/slicers-existing-architecture/34732/1 "2024-03-06T04:35:17Z")

</div>

Is it possible to port slicer’s existing architecture from single-threaded to multi-threaded?

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [March 6, 2024, 4:41am UTC](https://discourse.slicer.org/t/slicers-existing-architecture/34732/2 "2024-03-06T04:41:29Z")

</div>

Most modules and tools in slicer is already multi-threaded.

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [March 6, 2024, 3:50pm UTC](https://discourse.slicer.org/t/slicers-existing-architecture/34732/3 "2024-03-06T15:50:44Z")

</div>

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](https://discourse.slicer.org/t/new-surface-model-generation-method-surfacenets/32430)

---

<div class="post-metadata">

**Author:** ![MJamal](https://avatars.discourse-cdn.com/v4/letter/m/d26b3c/32.png) [@MJamal](https://discourse.slicer.org/u/MJamal)\
**Post date:** [March 7, 2024, 4:31am UTC](https://discourse.slicer.org/t/slicers-existing-architecture/34732/4 "2024-03-07T04:31:29Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![jamesobutler](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jamesobutler/32/7511_2.png) [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)\
**Post date:** [March 7, 2024, 12:09pm UTC](https://discourse.slicer.org/t/slicers-existing-architecture/34732/5 "2024-03-07T12:09:37Z")

</div>

There are plans to ultimately switch to Zlib-ng for some performance improvements. See this former thread that might be related to your topic.

> [@Parallel zip library for Slicer](https://discourse.slicer.org/t/parallel-zip-library-for-slicer/33290/3):
>
> As a drop-in replacement, we have plan to switch zlib with zlib-ng. See [COMP: Switch to modern maintained zlib-ng fork of zlib by jamesobutler · Pull Request #6708 · Slicer/Slicer · GitHub](https://github.com/Slicer/Slicer/pull/6708) Instead of transitioning to fastzip (currently unmaintained), we will likely add support for [GitHub - facebook/zstd: Zstandard - Fast real-time compression algorithm](https://github.com/facebook/zstd)

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [March 7, 2024, 1:39pm UTC](https://discourse.slicer.org/t/slicers-existing-architecture/34732/6 "2024-03-07T13:39:17Z")

</div>

@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](https://github.com/SlicerDMRI/SlicerDMRI/compare/master...pieper:SlicerDMRI:parallel-load) 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.

---

<div class="post-metadata">

**Author:** ![MJamal](https://avatars.discourse-cdn.com/v4/letter/m/d26b3c/32.png) [@MJamal](https://discourse.slicer.org/u/MJamal)\
**Post date:** [March 14, 2024, 4:30am UTC](https://discourse.slicer.org/t/slicers-existing-architecture/34732/7 "2024-03-14T04:30:27Z")

</div>

I need some time to discuss the bottlenecks here. I’ll also look into the references provided above and update you soon. Thanks 🙏