Good to hear! Thanks, Sascha
On 02/28/2014 05:57 PM, Rostislav Khlebnikov wrote: > 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 >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/mitk-users > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > mitk-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mitk-users ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
