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

[Miller, James V (Research)]

George, 

If you have the time, it would help to place timing points inside your
program.  There is class itkTimeProbesCollection that you could put in your
program.  The goal would be to time:

1. Loading the data
2. Preprocessing the data
3. Registration
4. Postprocessing
5. Saving the data

It would be great if we could get timings from 1.8 and 2.0 for each of these categories just to verify that all the timing loss is in the registration.

Otherwise, I agree that the move from an inline to a virtual function could be a cause for concern.  However, I would have hoped that the optimizer would have been able to do a better job.

Jim


-----Original Message-----
From: insight-users-bounces at itk.org
[mailto:insight-users-bounces at itk.org]On Behalf Of Li, George (NIH/NCI)
Sent: Monday, February 28, 2005 2:09 PM
To: 'Luis Ibanez'
Cc: Insight-users at itk.org
Subject: [Insight-users] RE: Performance change in registration between
ITK1.8 and ITK 2. 0


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