[Insight-users] Performance regression ImageSeriesReader? (with test)

[Roger Bramon Feixas]

First of all, I answer the Bill's question:
The problem isn't modality dependent, it also occurs on MR models. I did
some tests changing the pixel type but there isn't significant differences.
I show you the results. I used a CT model (
http://dl.dropbox.com/u/3613789/ct_anonymized.zip):

               PixelType     Reading directory    Update
ITK 2.8   unsigned short                  1024      2295
ITK 2.8              int                  1032      2419
ITK 3.16  unsigned short                  1018      4693
ITK 3.16             int                  1009      4724



Bradley,

I did the test using a computer which has Itel Core 2 Quad 2.4 GHz CPU with
4GB RAM. The OS is Windows XP 32bits. The data is on locale. During the
execution one of the CPU's is 100% full.

I did the test using 3 CT models:

Head CT (http://mri.radiology.uiowa.edu/VHDicom/VHFCT1mm/VHF-Head.tar.gz)
                Reading directory   UpdateOutputInformation
UpdateLargestPossibleRegion
Itk 2.8                       390                         4
           1409
Itk 3.16                      394                       452
           1502
________________________________________

CT example study which we work with (
http://dl.dropbox.com/u/3613789/ct_anonymized.zip)

                Reading directory   UpdateOutputInformation
UpdateLargestPossibleRegion
Itk 2.8                      1024                         9
           2260
Itk 3.16                     1030                      1666
           2975

_________________________________________

CALIX/CT1 abdomen/D30MN BILISCOPIN from OSIRIX Data (
http://pubimage.hcuge.ch:8080/DATA/CALIX.zip)

                Reading directory   UpdateOutputInformation
UpdateLargestPossibleRegion
Itk 2.8                       660                         7
          20380
Itk 3.16                      652                       850
          21053


Thanks!

Roger

On Mon, Mar 22, 2010 at 2:24 PM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:
>
> Hello,
> Can you please tell us a little more about your test data and computer.
What kind of file system is the data on ( locale or network)? How much
memory does the computer have? What is the size of the data? What is the
native pixel type of the data? What are the actual timings? Does the
execution seem to be CPU or IO bound?
> One of the changes that was made to the class was to populate the
MetaDataArray in the UpdataOutputInformation phase of the instead of the
UpdateOutputData part. This should be just reading the headers of the files
in the series. There were several reasons this change was made. To help
determine the cause of your slowness, lets break up the timing a little
further.
> Could you please call:
> start timer
> reader->UpdateOutputInformation();
> lap timer
> reader->UpdateLargestPossibleRegion();
> stop timer
> And post the timing results.
>
> Thanks,
> Brad
> On Mar 21, 2010, at 2:52 PM, Roger Bramon Feixas wrote:
>
> This week we updated our ITK version from 2.8 to 3.16  and we noticed the
medical models are loading 2x slower using the 3.16 ITK version. We use
itk::ImageSeriesReader and the problem is focused in its Update() method.
> I attached a simple test program which reproduces the problem and where we
can see that the Update() method is 2 times slower using ITK 3.16 vs. ITK
2.8.
> We compiled both versions using Visual Studio 2008 on Windows XP 32bits
and  we don't known if this problem also occurs in other platforms.
> I wonder if other itk users have this same performance problem and if
there is anybody can help us in order to solve it.
> Thanks!
>
> Roger
> <test.zip><ATT00001..txt>
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100322/25ef9cb4/attachment.htm>