Hello Sascha, that sounds very good! I'm really looking forward to the changes!
Please let me know if you need some additional info from me. Cheers, 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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mitk-users > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
