[Insight-developers] itk performance numbers

[Rupert Brooks]

Sorry if this repeats - i just got a bounce from Insight Developers, so im
trimming the message and resending....
--------------------------------------------------------------
Rupert Brooks
rupert.brooks at gmail.com



On Wed, Jul 25, 2012 at 4:03 PM, Rupert Brooks <rupert.brooks at gmail.com>wrote:

> It could be the Jacobian - the change from having a member jacobian, which
> made the transforms non-threadsafe, to an external jacobian that is filled
> by the GetJacobianWithRespectToParameters function places the
> responsibility for the jacobian allocation /deallocation in the Metric,
> where it used to be in the transform.
>
> Check around line 202 of itkMeanSquaresImageToImageMetric.
>
>   // Jacobian should be evaluated at the unmapped (fixed image) point.
>   TransformJacobianType jacobian;
>   transform->ComputeJacobianWithRespectToParameters(fixedImagePoint,
> jacobian);
>   for( unsigned int par = 0; par < this->m_NumberOfParameters; par++ )
>
> But this does not use operator=()... So maybe not what you are seeing.
>  Still looking...
>
> Rupert
> --------------------------------------------------------------
> Rupert Brooks
> rupert.brooks at gmail.com
>
>
>
>
> On Wed, Jul 25, 2012 at 1:51 PM, Bradley Lowekamp <blowekamp at mail.nih.gov>wrote:
>
>> Just to summarize:
>>
>> Most of the filters are about the same performance, however the otsu
>> thresholding is significantly slower.
>>
>> The registration is about 2x slower the v3.20.
>>
>> I quickly sampled the process during registration with on my apple and it
>> revealed the following interesting bit:
>>
>>                     88.45% itk::ImageToImageMetric<itk::Image<unsigned
>> char, 3u>, itk::Image<unsigned char, 3u>
>> >::GetValueAndDerivativeThread(unsigned int) const
>>                       56.62%
>> itk::MeanSquaresImageToImageMetric<itk::Image<unsigned char, 3u>,
>> itk::Image<unsigned char, 3u>
>> >::GetValueAndDerivativeThreadProcessSample(unsigned int, unsigned long,
>> itk::Point<double, 3u> const&, double, itk::CovariantVector<double, 3u>
>> const&) const
>>                         25.04%
>> vnl_matrix<double>::operator=(vnl_matrix<double> const&)
>>                                15.69% malloc
>>
>> So there is a significant amount of time spent creating and destroying
>> the matrix.
>>
>> Most likely this indicates that there is a variable inside the inner loop
>> in the registration that is requiring new and delete, we could likely
>> regain a significant portion of the performance by moving this allocation
>> out side of the loop.
>>
>> Brad
>>
>> <snipped>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20120725/969a3d32/attachment-0001.htm>