As suggested by @lassoan, if someone was time to invest, here are suggestions to address two specific bottlenecks:
(1) Scene model: A complete scene model is created in many MRML widgets (e.g., in each MRML node selector and node tree), with lots of observers on many nodes. Having a single scene model that contains all necessary information about all nodes in the scene (and a couple of filters&proxies) used by all widgets would probably make things scalable much better.
(2) Model hierarchies: Slicer doesn’t store low-level each low-level item (such as a fiducial point, a label, or segment) in a separate node for good reasons - mainly for performance for simplicity for module developers.
For example, at some point fiducials were attempted to be stored as “one node per fiducial” but it was complex to use and it was terribly slow. Changing fiducial management to have multiple markups in a single node solved the problems.
I think model nodes should work the same way: they should be able to manage many meshes internally (probably not just in a flat list but organized using tags or parent/children relationships), we should not require a separate node for each.
By investing a couple of weeks into either 1 and/or 2, you might achieve 10-100x performance improvement in managing large number of models (vs an optimistic 2-10x performance improvement by further general optimization of scene management).
In the past year @cpinter has made huge improvements in subject hierarchy:
it is a hierarchy that can handle all kinds of nodes (new node types and actions can be defined via plugins)
stores hierarchy information in a single MRML node (so there is no need for creating a hierarchy node for each model/annotation/etc. data node)
it can show internals of a MRML node in the tree (for example, segments of a are shown in the tree as child items of the segment node)
it can store the full state of the tree (order of elements, open/closed branch, etc. in contrast to model hierarchies, where this never worked correctly)
This single hierarchy can replace all other hierarchies (displayable, model, annotations) and it is much faster. I think in we should retire all the old hierarchies in Slicer 5 and switch to this one and then we would only need to implement the shared Qt scene model for a single hierarchy type.
model nodes should work the same way: they should be able to manage many meshes internally (probably not just in a flat list but organized using tags or parent/children relationships), we should not require a separate node for each.
This is exactly what Segmentation nodes do, except that they do more (representations, conversions, etc). I’d really feel it unnecessary to reinvent the wheel and create a third type of node in between Models and Segmentations, providing a subset of the Segmentation node’s features. If there is something this node should know that Segmentations doesn’t, then we should rather add that one feature to Segmentations.
Adding to @lassoan’s comment, SH2.0 is also fully compatible with the current model hierarchies, so this would make transition easier from the model hierarchies.