[Insight-users] Re: [Insight-developers] question for itk pipeline
expert
Luis Ibanez
luis.ibanez at kitware.com
Thu Dec 8 12:41:46 EST 2005
Well, the DebugMacro is an issue because it gets instantiated
in all the Set() and Get() methods of the toolkit. So it really
generates *a lot* of code. Probably thousands of instantiations
given that ITK has about 400 classes.
The modification we are proposing in the ProcessObject will get
compiled only once because ProcessObject is not a templated class.
So, this change is not invasive and it doesn't have a significant
impact on the performace of a filter. A TimeProbe simply read the
computer time when we call Start() and reads it again when we call
Stop(), then it computes the differnce.
Luis
-----------------------
Karthik Krishnan wrote:
> 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