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

[Li, George (NIH/NCI)]

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
>