I have found the reason.

The implementation of mitk::DataStorage::ComputeBoundingGeometry3D() (and some used time geometry functions) is unfavorable in context of arbitrary timegeometries.

1. ComputeBoundingGeometry3D() takes the min time point, max time point and the minimal time span between to time points of all data objects. This can lead to an extremly large number of time steps (and geometry constructions); e.g. A) if we have data with the default time span of 1 ms and a dynamic data set that spans over some minutes or hours (but has only <100 time steps) or B) or currently nearly every dynamic dataset (with arbitrary time geometry) because the last frame, is currently set to 1 ms if no explicit different max time bound is given.
2. TimeGeometries are not able to define bounding box update strategies if the geometry does not differ in time steps. Currently the base class time geometry has a non-virtual hard coded strategie to update the bounding box. It would be good if we can allow TimeGeometries to "signal" that there Geometry3D is always the same and thus spare the loop.

Number 1 draines the most CPU time and is the reason for a lot of the mentioned performance issues (in this and other task). Number 2 could lead to an additional speed up.

Regarding number 1:

I think it would be better to use, if possible an ArbitraryTimeGeometry in the method and really just generate all the timepoints that are available in the data collection. The bounding box computation could be keept as it is and then we initialize the ArbitraryTimeGeometry with the computed "bounding box" Geometry. The only change in behavior a can see so far is that the Image Navigation "time slider" may not slide "equidistant" anymore.

But I would like to discuss it before we are making any change regarding the computation of bounding boxes.