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

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

Dear Sacha,

just synced to the current master with the factoryless new macro branch 
merged. The performance just skyrocketed for me both in debug and 
release versions! Thanks a lot!

Rostislav.


On 13/02/2014 17:08, Sascha Zelzer wrote:
> Hi,
>
> thanks a lot for sharing your experience and evaluation.
>
> Your are right that the standard ::New() call adds a lot of overhead 
> and the provided flexibility (asking object factories) is rarely 
> needed. We indeed discussed the possibility to replace most (if not 
> all) ::New() methods in MITK with the "factory-less" version. We 
> actually agreed in general that this should be done but no action has 
> been carried out so far.
>
> You are also right that bug 14866 will drastically reduce the amount 
> of registered object factories and should result in an overall New() 
> speed-up.
>
> Concerning the lazy Geometry2D evaluation in SlicedGeometry3D and the 
> Clone() overhead, your ideas make totally sense. A student of ours is 
> currently investigating the class hierarchy of the geometry classes 
> also the Geometry2D / SlicedGeometry3D relationship with the goal of a 
> simplified hierarchy. We will certainly take your experiences into 
> account!
>
> So work on the factories and geometries is already being carried out 
> and the results should improve your runtime performance (timeframe: 
> ~3months). We will also pick up the factory-less New() discussion again.
>
> Thanks,
> Sascha
>
> On 02/12/2014 05:21 PM, Rostislav Khlebnikov wrote:
>> 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 :)
>>
>>
>> ------------------------------------------------------------------------------ 
>>
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk 
>>
>> _______________________________________________
>> mitk-users mailing list
>> mit...@li...
>> https://lists.sourceforge.net/lists/listinfo/mitk-users
>