[mitk-users] itkNewMacro performance and reslicing the view perpendicular to a spline

[Rostislav K. <ros...@kc...>]

Hello,

I would like to share some of my experiences working with geometries in 
MITK and some more or less general concerns that came out of them.

Right now I am implementing a rather common thing - reslicing the image 
perpendicularly to a curve (vessel path).
I have found a very old discussion about the similar task: 
http://sourceforge.net/mailarchive/message.php?msg_id=3457811
Even though it was from 2007, it seemed quite applicable to the current 
MITK version as well with some minor modifications.

So the first approach was to create the necessary PlaneGeometry 
instances, feed it to a SlicedGeometry3D and set this geometry to the 
renderer's SliceNavigationController.
It does indeed work as intended. However, the creation of slices is 
terribly slow: 4-5 seconds for 50 slices! Given that the slices might be 
required once every user click (e.g. the vessel path changes) this makes 
the application unusable.
I have experimented a little trying to find the reason why is it this 
slow and this is what I found.
1) <DataType>::New() is relatively slow because the call goes through 
the itk factories checking for overrides. In my current version of MITK 
Workbench with quite some plugins enabled - it is 81 factories which are 
checked.
2) All the geometries are cloned at least once upon setting the geometry 
to the SNC (which also works through <DataType>::New() and the time 
spent in allocating the objects is at least doubled).

I have made a small test to check the timings of creating a number of 
plane geometries. This is what I found:
1) Creating a plane geometry with all mitk factories registered takes 
about 5.5ms (*)
2) Creating a plane geometry without any mitk factories registered (only 
builtin ITK factories registered - ~11 of them) takes about 1.1ms
3) Substituting the itkNewMacro() with itkFactorylessNewMacro() in all 
the geometry classes makes the creation time to be about 0.9ms
These tests are obviously not conclusive and more extensive and 
controlled testing would be needed, but I think it shows the overall 
picture.

(*) Note, that the timings were taken in debug mode. However, when I 
compiled the first (non-test) version of my code in release the creation 
of 50 slices still took about 3 seconds, so I assume that in this 
particular case Release optimizations do not affect performance 
significantly.

Seems to me that at least one of the reasons for SlicedGeometry3D having 
special cases for lazy generation of Geometry2Ds in case it is evenly 
spaced is low performance of New().
Anyway, I wanted to draw the attention of MITK core developers to this 
problem as I am concerned that it may slow down the overall MITK 
performance unnecessarily.

I am unsure whether this work will reduce the number of registered mitk 
factories - http://bugs.mitk.org/show_bug.cgi?id=14866.

While I think that improving the New() performance is important overall, 
I feel like creating all the plane geometries at once is still not the 
best approach to my particular problem (reslicing perpendicular to the 
curve).
For now I decided to introduce lazy evaluation of Geometry2D's for my 
case by subclassing the SlicedGeometry3D. It works more or less fine, 
but I had to do some hacky things in copy constructor (because the 
SlicedGeometry3D has assertions that check if all Geometry2D's are not 
null if it is not evenly spaced, which is obviously not true for my 
case). However, I cannot avoid subclassing SlicedGeometry3D as it is 
used (through dynamic_cast) in the BaseRenderer.

I would propose to remove the specific implementation of lazy evaluation 
of Geometry2Ds for evenly spaced case from SlicedGeometry3D. It may be 
done by adding another hierarchy level (e.g. having 
EvenlySlicedGeometry3D : public SlicedGeometry3D which overrides 
GetGeometry2D) or by having something like a Geometry2DGenerator member 
which can then be subclassed for each type of lazy evaluation approach 
(e.g. EvenlySpacedSlicesGenerator which is able to create the slices 
using a reference slice, FullyStoredSlicesGenerator which can store all 
the possible slices, or in my case CurvePerpendicularSlicesGenerator). 
This is of course up to the core developers to choose the approach as I 
might miss some important use-cases for the SlicedGeometry3D.

I am really looking forward to hearing your thoughs on these topics.
If I missed some good solution for reslicing that is already possible in 
MITK - please give me a hint about it.

Rostislav.

PS:
I know this is quite some text here, but I tried to give as much 
(useful?) information as I could :)