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

Gaetan Lehmann gaetan.lehmann at jouy.inra.fr
Thu Dec 8 11:28:14 EST 2005 

On Thu, 08 Dec 2005 17:13:49 +0100, Luis Ibanez <luis.ibanez at kitware.com>  
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 ?

I sent a patch in my previous mail to implement the first solution.
Is it a good factor ? :-)

IMHO, the easier to use is the best, so I prefer the first one

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



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

More information about the Insight-users mailing list