[Insight-developers] question for itk pipeline expert

Luis Ibanez luis.ibanez at kitware.com
Thu Dec 8 11:13:49 EST 2005 

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

More information about the Insight-developers mailing list