[Insight-users] RE: Performance change in registration betwee n ITK 1.8 and ITK 2. 0

[Li, George (NIH/NCI)]

Zach and Luis:

Thanks for the confirmation. In my case, actually, two
IsInsideBuffer(...) functions are called in a cascade.
So, the effect is doubled. Also, inline is a hint, not
a must, to a compiler to do the code substitution, so  
it can be compiler dependent, according to Stroustrup's 
book. The compilers that I have used so far, they all 
follow the "hint", meaning that there is a performance
difference.

Regards,

George


-----Original Message-----
From: Zachary Pincus [mailto:zpincus at stanford.edu] 
Sent: Monday, February 28, 2005 3:08 PM
To: insight-users at itk.org Users
Subject: Re: [Insight-users] RE: Performance change in registration between
ITK 1.8 and ITK 2. 0


Luis and George,

Thanks for bringing this up. Changing the IsInsideBuffer calls to be  
final (non-virtual) realizes some modest gains (~3-5%, in some somewhat  
informal tests) for me too. I'm using PCA shape models, which call  
IsInsideBuffer a lot, typically in the inner loop of an optimization.

Zach

On Feb 28, 2005, at 11:09 AM, Li, George (NIH/NCI) wrote:

> Hi, Luis:
>
> Thanks for your comments and suggestions, as usual.
>
> I believe that the change of the overloaded function:
> bool IsInsideBuffer(...) from inline to virtual must
> be the reason for the performance cost. To avoid of
> another build of ITK, I only did an estimation on the performance.
>
> Here is what I did: inside the three overloaded calls,
> I put a break point, and run the application in debug
> mode. Therefore, I can monitor how many calls these
> functions are called in each iteration within the optimization. 
> Presumably, for every sampling point made, IsInsideBuffer(...) is 
> called, which is a lot. In a default setting for the Mattes metric, 
> 10,000 sampling points are used. So the cost of a function
> call, instead of inline insert, can added up. Since
> itkImageFunction.h has already used a virtual table,
> so, there should not cost too much additional from
> a regular function call to a virtual function call.
>
> Anyway, in principle, this test is consistent with the reduction of 
> the performance. So, my question now is that since the ray cast 
> interpolator is a new feature, can another set of overloaded functions 
> be created, instead of sharing with other interpolators, which
> is definitely not going to need "virtual" functions?
>
> Of course, there is always a tradeoff between code Reusability and 
> performance.
>
> Regards,
>
> George
>
>
>
> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
> Sent: Friday, February 25, 2005 6:28 PM
> To: Li, George (NIH/NCI)
> Cc: Insight-users at itk.org
> Subject: Re: Performance change in registration between ITK 1.8 and
> ITK 2.0
>
>
>
> Hi George,
>
> Thanks for letting us know about your performance test.
>
>
> I assume that you are compiling your code for Release...
> is that right ?
>
> Is there a chance that you could share that test with us ?
> That would help us to locate the potential source of performance  
> change.
>
>
>
> One potential suspect is the recent modification of one
> method of the interpolator in order to support the 3D/2D registration  
> with
> the ray cast interpolator.
>
> This modification involved to make some methods "virtual".
> This could have resulted in the peformance degradation
> that you are observing.
>
>
> You may easily verify this hypothesis by reverting the
> change and rerunning your performance test.
>
> The change was in
>
>    Insight/Code/Common/itkImageFunction.h
>
>
> http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkImageFunction.h? 
> root=I
> nsight&sortby=date&r2=1.35&r1=1.34
>
> This was related to Bug # 1160.
>
>
>
>
>
>
> Please let us know what you find.
>
>
>     Thanks
>
>
>        Luis
>
>
>
>
> -----------------------------
> Li, George (NIH/NCI) wrote:
>
>> Hi, Luis and all users:
>>
>> I have done a little performance testing between ITK2.0.0 and
>> ITK1.8.0. Unfortunately, using ITK2.0.0, a registration work is about
>> 20% slower. I don't know if anyone else have experienced this.
>>
>> Here is what I did. My code is to do 3D image registration using
>> Mattes metric, evolutionary optimizer, and Versor3DTransform. For
>> fixed 500 iterations, it took 60 seconds using ITK2.0.0, while it took
>> 48 seconds using ITK1.8.0. These numbers are average of three runs
>> with the same two images on the same machine under identical
>> conditions.
>>
>> This is just to post a concern about the performance, and hopefully,
>> it would not become a trend for future release. Usually, I would have
>> to iterate 10,000 times for a good registration, which is consistent
>> with what in Martin Styner's paper. If my program were used in clinic,
>> to let users wait another 20% more time after a new release, they
>> probably would rather stay with the old version. That is reality.
>>
>> Thanks for all the work to keep ITK growing.
>>
>> Regards,
>>
>> George
>>
>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>

_______________________________________________
Insight-users mailing list
Insight-users at itk.org
http://www.itk.org/mailman/listinfo/insight-users