[Insight-users] Re: [Insight-developers] question for itk pipeline expert

Bill Lorensen wlorens1 at nycap.rr.com
Thu Dec 8 11:54:53 EST 2005


You can turn off the progress display with watcher.QuietOn();

At 11:51 AM 12/8/2005, Gaetan Lehmann wrote:

>SimpleFilterWatcher display is too verbose for this task.
>But it is really nice to test the events of a filter. I will use it
>instead of my custom class :-)
>
>On Thu, 08 Dec 2005 17:22:09 +0100, Bill Lorensen <wlorens1 at nycap.rr.com>
>wrote:
>
>>itkSimpleFIlterWatcher could be modified to use the TimeProbesCollector.
>>It is very easy to use:
>>
>>itk::SimpleFilterWatcher filter1Watcher(filter1,"AnisotropicDIffusion");
>>itk::SimpleFilterWatcher filter2Watcher(filter2,"MyGradientFIlter");
>>
>>I'll look into adding it.
>>
>>Bill
>>
>>At 11:13 AM 12/8/2005, Luis Ibanez wrote:
>>
>>>Karthik has a good point here.
>>>
>>>We could simply add a TimeProbe at the top level of the filters.
>>>
>>>For example in the ProcessObject class, in the
>>>method GenerateOutputData() in line 926 of
>>>
>>>     Insight/Code/Common/
>>>              itkProcessObject.cxx
>>>
>>>
>>>The TimeProbe will be started before calling
>>>GenerateData() and it will be stopped just
>>>after it. In this way, all the filter will
>>>inherit that functionality.
>>>
>>>Adding a time probe in this way should not
>>>result in any significant overhead in memory
>>>or execution time.
>>>
>>>We should also add a method for reseting the
>>>TimeProbe from the outside of the ProcessObject,
>>>as well as for queering the report of the TimeProbe.
>>>
>>>An alternative method is to create a TimeProbeObserver
>>>class that will be a simple Command observer that will
>>>be listening for the StartEvent, and the EndEvent, and
>>>when each event is received, it will Start() and Stop()
>>>and internal TimeProbe accordingly.
>>>
>>>The advantage of this approach is that the performance
>>>measurement will be done without invading the filter.
>>>
>>>The disadvantage will be that the developer will have
>>>to instantiate the class, and do the connections.
>>>
>>>
>>>The first option seems to be more convenient...
>>>
>>>
>>>Do you see other factors that may tilt the preference
>>>in one direction or another ?
>>>
>>>
>>>
>>>
>>>    Luis
>>>
>>>
>>>-----------------------
>>>Karthik Krishnan wrote:
>>>>|
>>>>|||
>>>>Gaetan Lehmann wrote:
>>>>
>>>>>
>>>>>Hi Luis,
>>>>>
>>>>>Yes, I can go this way, but:
>>>>>- If the execution time can be integrated in the filter (we accept to
>>>>>have  a new attribute in the filter), then it should be implemented
>>>>>in a common  class of all filters, so the execution time of all
>>>>>filters can be measured  without having to duplicate code.
>>>>
>>>>|
>>>>It should be possible to define a macro that can be #defined via CMake
>>>>and collects times taken by GenerateData methods of filters via a
>>>>TimeProbesCollector. I don't know if a lot of people need this
>>>>functionality, but if that's so it should be easy to add. There are
>>>>classes for this purpose already. I guess they just need to be hooked
>>>>into appropriate places.
>>>>regards
>>>>karthik
>>>>|
>>>>
>>>>>- If the execution can't be integrated in the filter (because we
>>>>>don't  want of another attribute), then I will have to remove/comment
>>>>>the  corresponding code before submitting the filter, and so measure
>>>>>will be  hard to reproduce
>>>>>- There is really a problem that I can't locate, and which make ITK
>>>>>use a  significant amount of time. It should be fixed :-)
>>>>>
>>>>>Gaetan
>>>>>
>>>>>On Thu, 08 Dec 2005 13:26:39 +0100, Luis Ibanez
>>>>><luis.ibanez at kitware.com>  wrote:
>>>>>
>>>>>>
>>>>>>Hi Gaetan,
>>>>>>
>>>>>>
>>>>>>      Gaetan Lehmann wrote:
>>>>>>
>>>>>>      > how can I evaluate the performance of the
>>>>>>      > filters in that situation ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>     Enjoy the Power of Open Source !
>>>>>>
>>>>>>
>>>>>>
>>>>>>     Go to the source code of the filter that you
>>>>>>     want to profile and add a TimeProbe as a member
>>>>>>     variable.
>>>>>>
>>>>>>     If the filter is not threaded, simply Start the
>>>>>>     TimeProbe at the beginning of the GenerateData()
>>>>>>     method, and Stop it at the end of the same method.
>>>>>>
>>>>>>     If the filer is threaded, Start() the TimeProbe in
>>>>>>     the "BeforeThreadedGenerateData()" method and
>>>>>>     Stop() the TimeProbe in the "AfterThreadedGenerateData()"
>>>>>>     method.
>>>>>>
>>>>>>
>>>>>>
>>>>>>     If you want to force the filters to re-execute,
>>>>>>     multiple times in order to have better statistics,
>>>>>>     then you can invoke the "Modified()" method on them
>>>>>>     before calling "Update()".
>>>>>>
>>>>>>
>>>>>>     Add a Get method to the filter in order to gain
>>>>>>     access to the probe, so when you are done running
>>>>>>     the filters you can invoke from outside the filter
>>>>>>     the report of the Time Probe.  At that point, pay
>>>>>>     particular attention at the report on "Number of
>>>>>>     Starts" and "Number of Stops", since that will
>>>>>>     tell you how many times the "Generate Data" method
>>>>>>     was executed.
>>>>>>
>>>>>>
>>>>>>        Regards
>>>>>>
>>>>>>
>>>>>>
>>>>>>         Luis
>>>>>>
>>>>>>
>>>>>>----------------------
>>>>>>Gaetan Lehmann wrote:
>>>>>>
>>>>>>>  Hi Bill,
>>>>>>>  No, there is no ReleaseDataFlagOn() in the filters used.
>>>>>>>I have displayed the progress of all the filters to verify that
>>>>>>>they  are  not reexecuted if they shouldn't, and everything looks
>>>>>>>nice (but  the  timing are still not what they should).
>>>>>>>It's a major problem for me: how can I evaluate the performance of
>>>>>>>the   filters in that situation ?
>>>>>>>  Gaetan
>>>>>>>  On Wed, 07 Dec 2005 21:12:55 +0100, Bill Lorensen
>>>>>>><wlorens1 at nycap.rr.com>  wrote:
>>>>>>>
>>>>>>>>Are you using ReleaseDataFlagOn in any of your filters. Perhaps
>>>>>>>>something is re-executing.
>>>>>>>>
>>>>>>>>Bill
>>>>>>>>
>>>>>>>>At 07:42 AM 12/7/2005, Gaetan Lehmann wrote:
>>>>>>>>
>>>>>>>>>Hi,
>>>>>>>>>
>>>>>>>>>I'm trying to measure the execution time of a new filter.
>>>>>>>>>It's done with
>>>>>>>>>http://voxel.jouy.inra.fr/darcs/contrib-itk/regionalExtrema/perf3D.cxx
>>>>>>>>>Here are the results I get:
>>>>>>>>>
>>>>>>>>>[glehmann at marvin build]$ ./perf3D ../ESCells.img
>>>>>>>>>#F      concave vrmin   rmin
>>>>>>>>>0       17.874  2.592   1.74
>>>>>>>>>1       21.022  3.613   2.799
>>>>>>>>>
>>>>>>>>>There is a problem: rmin is a sequence of filters which include
>>>>>>>>>vrmin,  and
>>>>>>>>>so rmin should take more time than vrmin.
>>>>>>>>>Now, if I comment rmin measure and update, I get
>>>>>>>>>
>>>>>>>>>[glehmann at marvin build]$ ./perf3D ../ESCells.img
>>>>>>>>>#F      concave vrmin   rmin
>>>>>>>>>0       17.578  0       2.614
>>>>>>>>>1       21.276  0       3.722
>>>>>>>>>
>>>>>>>>>Again, there is something wrong: I should get the same value than
>>>>>>>>>before
>>>>>>>>>for rmin if vrmin is not updated.
>>>>>>>>>
>>>>>>>>>I think there is something hidden in the execution of the
>>>>>>>>>pipeline,  but  I
>>>>>>>>>can't get what.
>>>>>>>>>Can someone look at the code above and tell me what I'm doing
>>>>>>>>>wrong ?
>>>>>>>>>
>>>>>>>>>I'm using ITK 2.4.1, cmake 2.2.2 and gcc 4.0.1
>>>>>>>>>
>>>>>>>>>Thanks,
>>>>>>>>>
>>>>>>>>>Gaetan
>>>>>>>>>
>>>>>>>>>-- Gaëtan Lehmann
>>>>>>>>>Biologie du Développement et de la Reproduction
>>>>>>>>>INRA de Jouy-en-Josas (France)
>>>>>>>>>tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
>>>>>>>>>http://voxel.jouy.inra.fr
>>>>>>>>>_______________________________________________
>>>>>>>>>Insight-developers mailing list
>>>>>>>>>Insight-developers at itk.org
>>>>>>>>>http://www.itk.org/mailman/listinfo/insight-developers
>>>>>>>>
>>>>>>>>
>>>>>
>>>>_______________________________________________
>>>>Insight-developers mailing list
>>>>Insight-developers at itk.org
>>>>http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>>_______________________________________________
>>>Insight-users mailing list
>>>Insight-users at itk.org
>>>http://www.itk.org/mailman/listinfo/insight-users
>>
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers at itk.org
>>http://www.itk.org/mailman/listinfo/insight-developers
>
>
>
>--
>Gaëtan Lehmann
>Biologie du Développement et de la Reproduction
>INRA de Jouy-en-Josas (France)
>tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
>http://voxel.jouy.inra.fr
>_______________________________________________
>Insight-developers mailing list
>Insight-developers at itk.org
>http://www.itk.org/mailman/listinfo/insight-developers



More information about the Insight-developers mailing list