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

Karthik Krishnan Karthik.Krishnan at kitware.com
Thu Dec 8 11:49:05 EST 2005


Sorry to be a bother, but I still think it should be a macro or 
something whose compilation could be disabled from CMake if necessary. 
Aren't we already having problems with DebugMacros on Borland ?

My two cents
karthik

Bill Lorensen 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
>
>
>


More information about the Insight-developers mailing list