Hi,<div><br></div><div>I opened two report issues:</div><div><br></div><div><a href="http://public.kitware.com/Bug/view.php?id=10456">http://public.kitware.com/Bug/view.php?id=10456</a> : Performance problem of <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">UpdateOutputInformation</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><a href="http://public.kitware.com/Bug/view.php?id=10457">http://public.kitware.com/Bug/view.php?id=10457</a> : Performance problem related to the TransferSyntax</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Thanks you for all of your help and your quick reply. If I can help you I will do it.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Roger<br>
</span></font><br><div class="gmail_quote">On Wed, Mar 24, 2010 at 3:09 PM, Bradley Lowekamp <span dir="ltr"><<a href="mailto:blowekamp@mail.nih.gov">blowekamp@mail.nih.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">Hello Roger,<div><br></div><div>For the performance issue in UpdateOutputInformation could you please follow the procedures for reporting a bug. This will aid in future tracking and maintenance. </div>
<div><br></div><div><a href="http://www.itk.org/Wiki/ITK_Procedure_for_Contributing_Bug_Fixes" target="_blank">http://www.itk.org/Wiki/ITK_Procedure_for_Contributing_Bug_Fixes</a></div><div><br></div><div><br></div><div>As for the performance that is a related to the TransferSintax that is a separate issue likely cause by something in side the dicom library.</div>
<div><br></div><div>Brad</div><div><div></div><div class="h5"><div><br></div><div><br><div><div>On Mar 24, 2010, at 8:24 AM, Roger Bramon Feixas wrote:</div><br><blockquote type="cite"><font face="'courier new', monospace">Hi,</font><div>
<font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">I changed the line in method </font><span style="font-size:13px;border-collapse:collapse"><font face="'courier new', monospace">GenerateOutputInformation</font><font face="'courier new', monospace"> and now I show you the results. I used the same data of the previous tests.</font></span></div>
<div><span style="font-size:13px;border-collapse:collapse"><font face="'courier new', monospace"><br></font></span></div><div><span style="font-size:13px;border-collapse:collapse"><font face="'courier new', monospace">We can observe the </font><font face="'courier new', monospace">UpdateOutputInformation</font><font face="'courier new', monospace"> of 3.16 patched is much faster than v3.16 released. However, if we compare 2.8 and 3.16patched, in some cases 2.8 is quite faster. This performance difference can be appreciated in data which its </font><font face="'courier new', monospace">TransferSintax</font><font face="'courier new', monospace"> is Little </font><font face="'courier new', monospace">Endian</font><font face="'courier new', monospace"> Implicit (test 2, 4, 7) and it exists in both update methods (</font><font face="'courier new', monospace">UpdateOutputInformation</font><font face="'courier new', monospace"> and </font><font face="'courier new', monospace">UpdateLargestPossibleRegion</font><font face="'courier new', monospace">) even though the most critical is the </font></span><span style="font-size:13px;border-collapse:collapse"><font face="'courier new', monospace">UpdateLargestPossibleRegion</font><font face="'courier new', monospace"> because it needs seconds instead of milliseconds.</font></span></div>
<div><font face="'courier new', monospace"><span style="border-collapse:collapse"><br></span></font></div><div><font face="'courier new', monospace"><span style="border-collapse:collapse">Nowadays, we aren't using streaming. Therefore, we collaborate with you in order to solve the problem, but we are really interested to fix the usual use case because we need the performance improvement quite soon.</span></font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">The results of the experiment:</font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">1. Head (<a href="http://mri.radiology.uiowa.edu/VHDicom/VHFCT1mm/VHF-Head.tar.gz" target="_blank">http://mri.radiology.uiowa.edu/VHDicom/VHFCT1mm/VHF-Head.tar.gz</a>)</font></div>
<div><div><font face="'courier new', monospace">TransferSyntax: Little Endian Explicit</font></div><div><font face="'courier new', monospace">117MB</font></div>
<div><font face="'courier new', monospace">234 Files</font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"> Read dir UpdateOutputInformation UpdateLargestPossibleRegion</font></div>
<div><font face="'courier new', monospace"> ITK 2.8 385 4 1435 </font></div><div><font face="'courier new', monospace">ITK 3.16 400 4 1485</font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">__________________________________</font></div><div>
<font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace">2. CT example study we work with </font></div><div><font face="'courier new', monospace">(<a href="http://dl.dropbox.com/u/3613789/ct_anonymized.zip" target="_blank">http://dl.dropbox.com/u/3613789/ct_anonymized.zip</a>)</font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">TransferSyntax: Little Endian Implicit</font></div><div>
<font face="'courier new', monospace">124MB</font></div><div><font face="'courier new', monospace">243 Files</font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace"> Read dir UpdateOutputInformation UpdateLargestPossibleRegion</font></div><div><font face="'courier new', monospace"> ITK 2.8 1013 9 2186</font></div>
<div><font face="'courier new', monospace">ITK 3.16 1003 14 2999</font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace">___________________________________</font></div><div><font face="'courier new', monospace"><br></font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">3. CALIX/CT1 abdomen/D30MN BILISCOPIN from OSIRIX Data </font></div>
<div><font face="'courier new', monospace">(<a href="http://pubimage.hcuge.ch:8080/DATA/CALIX.zip" target="_blank">http://pubimage.hcuge.ch:8080/DATA/CALIX.zip</a>)</font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace">TransferSyntax: JPEG2000</font></div><div><font face="'courier new', monospace">130MB</font></div><div>
<font face="'courier new', monospace">243 files</font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"> Read dir UpdateOutputInformation UpdateLargestPossibleRegion</font></div>
<div><font face="'courier new', monospace"> ITK 2.8 642 6 20156</font></div><div><font face="'courier new', monospace">ITK 3.16 653 7 20714</font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">_____________________________________</font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace">4. Mr Perfusion data</font></div><div><font face="'courier new', monospace"><a href="http://dl.dropbox.com/u/3613789/perfusion_implicit_anonymized.zip" target="_blank">http://dl.dropbox.com/u/3613789/perfusion_implicit_anonymized.zip</a> </font></div>
<div><font face="'courier new', monospace">(The test crashs when the v2.8 is used. I did the test without anonymize it)</font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace">TransferSyntax: Little Endian Implicit</font></div><div><font face="'courier new', monospace">41,9MB</font></div>
<div><font face="'courier new', monospace">1080 Files</font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"> Read dir UpdateOutputInformation UpdateLargestPossibleRegion</font></div>
<div><font face="'courier new', monospace"> ITK 2.8 4032 9 4809</font></div><div><font face="'courier new', monospace">ITK 3.16 4051 25 13376</font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">_____________________________________________</font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace">5. Mr Perfusion data (4) recodified</font></div><div><font face="'courier new', monospace"><a href="http://dl.dropbox.com/u/3613789/perfusion_explicit_anonymized.zip" target="_blank">http://dl.dropbox.com/u/3613789/perfusion_explicit_anonymized.zip</a></font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">TransferSyntax: Little Endian Explicit</font></div><div>
<font face="'courier new', monospace">41,9MB</font></div><div><font face="'courier new', monospace">1080 Files</font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace"> Read dir UpdateOutputInformation UpdateLargestPossibleRegion</font></div><div><font face="'courier new', monospace"> ITK 2.8 15480 31 17148</font></div>
<div><font face="'courier new', monospace">ITK 3.16 15522 31 16821</font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">_____________________________________________</font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace">6. Mr Perfusion data (4) anonymized by Osirix. All private tags were removed.</font></div><div><font face="'courier new', monospace"><a href="http://dl.dropbox.com/u/3613789/perfusion_anonymized_osirix.zip" target="_blank">http://dl.dropbox.com/u/3613789/perfusion_anonymized_osirix.zip</a></font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">TransferSyntax: Little Endian Explicit</font></div><div>
<font face="'courier new', monospace">36,9MB</font></div><div><font face="'courier new', monospace">1080 Files</font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace"> Read dir UpdateOutputInformation UpdateLargestPossibleRegion</font></div><div><font face="'courier new', monospace"> ITK 2.8 3898 9 4669</font></div>
<div><font face="'courier new', monospace">ITK 3.16 3869 9 5330</font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">_______________________________________________</font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">7. CT Abdomen</font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">TransferSintax: Little Endian Implicit</font></div><div>
<font face="'courier new', monospace">271MB</font></div><div><font face="'courier new', monospace">531 Files</font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace"> Read dir UpdateOutputInformation UpdateLargestPossibleRegion</font></div><div><font face="'courier new', monospace"> ITK 2.8 1798 8 4343</font></div>
<div><font face="'courier new', monospace">ITK 3.16 1791 13 6233</font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace">________________________________________________</font></div>
<div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br>
</font></div><div><font face="'courier new', monospace">Roger</font></div><div><font face="'courier new', monospace"><br></font></div><div><font face="'courier new', monospace"><br>
</font></div><div class="gmail_quote">On Tue, Mar 23, 2010 at 11:05 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Roger,<br>
<br>
Thanks for all of your help. We're getting close to a solution.<br>
<font color="#888888"><br>
Bill<br>
</font><div><div></div><div><br>
On Tue, Mar 23, 2010 at 2:57 PM, Roger Bramon Feixas<br>
<<a href="mailto:rogerbramon@gmail.com" target="_blank">rogerbramon@gmail.com</a>> wrote:<br>
> Bill,<br>
> Now I'm at home. You will have the results of the experiment tomorrow<br>
> morning.<br>
> Thanks,<br>
> Roger<br>
><br>
> On Tue, Mar 23, 2010 at 8:44 PM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Sounds good. So you are saying that in the<br>
>> ImageSeriesReader<TOutputImage><br>
>> ::GenerateOutputInformation<br>
>><br>
>> that the number of files that are processed will be only 2.<br>
>><br>
>> Bill<br>
>><br>
>> On Tue, Mar 23, 2010 at 12:39 PM, Bradley Lowekamp<br>
>> <<a href="mailto:blowekamp@mail.nih.gov" target="_blank">blowekamp@mail.nih.gov</a>> wrote:<br>
>> > Bill:<br>
>> > My proposed solution is to use the old behavior but use a time stamp to<br>
>> > avoid the extra updates of the MDDA when streaming.<br>
>> > The requested region is set after UpdateOutputInformation is executed,<br>
>> > so it<br>
>> > can't be toggled during the this phase of execution.<br>
>> ><br>
>> > On Mar 23, 2010, at 3:28 PM, Bill Lorensen wrote:<br>
>> ><br>
>> > Can we check if streaming is on and revert to the old behavior if it is<br>
>> > off?<br>
>> ><br>
>> > This is a huge performance penalty to support streaming which is<br>
>> > important but no the usual use case.<br>
>> ><br>
>> ><br>
>> > On Tue, Mar 23, 2010 at 12:12 PM, Bradley Lowekamp<br>
>> > <<a href="mailto:blowekamp@mail.nih.gov" target="_blank">blowekamp@mail.nih.gov</a>> wrote:<br>
>> ><br>
>> > Bill,<br>
>> ><br>
>> > Going back would have horrible effects for streaming. It would make<br>
>> > slice by<br>
>> ><br>
>> > slice streaming an n^2 algorithm, which is far worse then the current<br>
>> > order<br>
>> ><br>
>> > of N hindrance for normals Updates. We must make some improvements from<br>
>> > 2.8.<br>
>> ><br>
>> > If we declare the the MetaDataDictionary is suppose to be updated in the<br>
>> ><br>
>> > update data phase. ( the ImageFileReader does it in the<br>
>> ><br>
>> > UpdateOutputInformation phase ) Then the prior stated point 1 design<br>
>> ><br>
>> > requirement is gone. And the following solution come to mind:<br>
>> ><br>
>> > 1) Modify the GetMMDA methods to produce a warning if the update output<br>
>> > data<br>
>> ><br>
>> > has not been called. This is to be nice if some users now expect<br>
>> ><br>
>> > UpdateOutputInformation to produce the MDDA.<br>
>> ><br>
>> > 2) Add a time stamp for the MMDA, so that when streaming the MMDA is<br>
>> > only<br>
>> ><br>
>> > updated once and not every time a region is requested.<br>
>> ><br>
>> > Additionally I believe that we need better DICOM test data which include<br>
>> ><br>
>> > more tags similar to real world data.<br>
>> ><br>
>> > Brad<br>
>> ><br>
>> > On Mar 23, 2010, at 2:54 PM, Bill Lorensen wrote:<br>
>> ><br>
>> > The UpdateInformation is supposed to update origin, spacing,<br>
>> ><br>
>> > direction, pixel type, etc. I don't think it is supposed to completely<br>
>> ><br>
>> > populate the meta data dictionary. At least until itk 2.8 it did not.<br>
>> ><br>
>> > Why not revert back to the old behavior as a sort term fix.<br>
>> ><br>
>> > I think this performance hit needs to be repaired before we release<br>
>> ><br>
>> > 3.16. This has been causing major pain for Slicer3 users who<br>
>> ><br>
>> > frequently use dicom. Fortunately for us, Roger brought it to light.<br>
>> ><br>
>> > We missed it because our performance testing is weak.<br>
>> ><br>
>> > There are other issues for sure.<br>
>> ><br>
>> > Bill<br>
>> ><br>
>> > On Tue, Mar 23, 2010 at 11:45 AM, Bradley Lowekamp<br>
>> ><br>
>> > <<a href="mailto:blowekamp@mail.nih.gov" target="_blank">blowekamp@mail.nih.gov</a>> wrote:<br>
>> ><br>
>> > Bill,<br>
>> ><br>
>> > After my tests I agree that reading the headers in DICOM files is a<br>
>> ><br>
>> > surprisingly expensive operation as such it should be minimized. The<br>
>> > coping<br>
>> ><br>
>> > of the MDAs is insignificant performance wise. I believe that the best<br>
>> ><br>
>> > solution would be to have a dedicated DICOM series readers, which also<br>
>> ><br>
>> > removes the extra header reads needed for the name generation as well as<br>
>> > the<br>
>> ><br>
>> > extra one in the UpdateOutputInformation.<br>
>> ><br>
>> > If we assume that the usually way to utilize the reader is to just<br>
>> > Update,<br>
>> ><br>
>> > or stream Update, then the additional read of the headers appears<br>
>> ><br>
>> > unnecessary.<br>
>> ><br>
>> > I believe a solution would be to make the GetMDDA method smarter, and by<br>
>> ><br>
>> > default update this MDDA in the UpdateData. A time stamp would need to<br>
>> > be<br>
>> ><br>
>> > used for the MDDA to check when it needs to be updated in the UpdateData<br>
>> ><br>
>> > methods. For streaming, the first time through would require reading all<br>
>> > of<br>
>> ><br>
>> > the headers for the MDDA, this should bring the time stamp up to date.<br>
>> > The<br>
>> ><br>
>> > GetMDDA methods could also check this timestamp and perform the reading<br>
>> > of<br>
>> ><br>
>> > the headers if it's out of date. This is my best current idea on how to<br>
>> ><br>
>> > maintain the 1) and 2) I previously mentioned.<br>
>> ><br>
>> > Brad<br>
>> ><br>
>> > On Mar 23, 2010, at 12:33 PM, Bill Lorensen wrote:<br>
>> ><br>
>> > Brad,<br>
>> ><br>
>> > I have an itk 2.8 checkout. The difference is due to the processing of<br>
>> ><br>
>> > all files in the GenerateOutputInformation method. In the past, only<br>
>> ><br>
>> > two files were processed. If I restrict the number of files to 2<br>
>> ><br>
>> > rather that number of files, I get pretty reasonable speeds.<br>
>> ><br>
>> > Roger,<br>
>> ><br>
>> > As an experiment (and definitely not a fix!), can you in the method<br>
>> ><br>
>> > void ImageSeriesReader<TOutputImage><br>
>> ><br>
>> > ::GenerateOutputInformation(void)<br>
>> ><br>
>> > change the line:<br>
>> ><br>
>> > for ( int i = 0; i != numberOfFiles; ++i )<br>
>> ><br>
>> > to<br>
>> ><br>
>> > for ( int i = 0; i != 2; ++i )<br>
>> ><br>
>> > and rerun your tests.<br>
>> ><br>
>> > Bill<br>
>> ><br>
>> ><br>
>> > On Tue, Mar 23, 2010 at 8:59 AM, Bradley Lowekamp<br>
>> ><br>
>> > <<a href="mailto:blowekamp@mail.nih.gov" target="_blank">blowekamp@mail.nih.gov</a>> wrote:<br>
>> ><br>
>> > Bill,<br>
>> ><br>
>> > That is only the half of it. Every time an ImageFileReader is used 3<br>
>> > MDDs<br>
>> ><br>
>> > (meta data dictionaries) are created, one in the ImageIO, one in the<br>
>> ><br>
>> > ImageFileReader, and one in the output Image. This is in addition to the<br>
>> > two<br>
>> ><br>
>> > copies, you pointed out in ImageSeriesReader. Clearly reading with an<br>
>> ><br>
>> > ImageFileReader the MDD scales very poorly as the it's size increases. I<br>
>> ><br>
>> > still have the remaining performance questions:<br>
>> ><br>
>> > How much time is spent coping the MDD vs reading? (leaning towards<br>
>> > reading<br>
>> ><br>
>> > as very expensive)<br>
>> ><br>
>> > As pointed out in Roger's most recent performance tests, there appears<br>
>> > to be<br>
>> ><br>
>> > some additional performance problems in the UpdateData, part. This is<br>
>> ><br>
>> > independent of the additional MDD read in the UpdateOutputInformation.<br>
>> > This<br>
>> ><br>
>> > is definitely another problem, perhaps inside the DICOM library.<br>
>> ><br>
>> > The change of moving (apparently duplicating) the copying to MDDs to the<br>
>> > MDD<br>
>> ><br>
>> > array was added over a year ago, when streaming support was added. If I<br>
>> ><br>
>> > recall correctly the two motivating factors were 1) the MDD array is<br>
>> > output<br>
>> ><br>
>> > information and logically should be updating during the<br>
>> ><br>
>> > UpdateOutputInformation part of the pipeline 2) when streaming each file<br>
>> ><br>
>> > should not need to be read to create the MMD array. I don't recall where<br>
>> ><br>
>> > this discussion took place right now.<br>
>> ><br>
>> > I will run some performance test to try to figure out where the time is<br>
>> ><br>
>> > being spent. Without changing 1 from above, I am not sure how much could<br>
>> > be<br>
>> ><br>
>> > gained.<br>
>> ><br>
>> > Looking at the performance numbers of the Read Directory part, I would<br>
>> > guess<br>
>> ><br>
>> > that the meta data is also read there. I believe that an idea solution<br>
>> > would<br>
>> ><br>
>> > only read this information once. But that is beyond this scope.<br>
>> ><br>
>> > Brad<br>
>> ><br>
>> > On Mar 22, 2010, at 11:20 PM, Bill Lorensen wrote:<br>
>> ><br>
>> > Brad,<br>
>> ><br>
>> > It looks like the meta data array is populated in both the<br>
>> ><br>
>> > GenerateOutputInformation and GenerateData. Also all slices are<br>
>> ><br>
>> > processed in GenerateOutputInformation. In 2.8, only 2 slices were<br>
>> ><br>
>> > processed.<br>
>> ><br>
>> > Why were these changes made? We are also seeing bad dicom performance<br>
>> ><br>
>> > in Slicer3.<br>
>> ><br>
>> > Bill<br>
>> ><br>
>> > On Mon, Mar 22, 2010 at 6:24 AM, Bradley Lowekamp<br>
>> ><br>
>> > <<a href="mailto:blowekamp@mail.nih.gov" target="_blank">blowekamp@mail.nih.gov</a>> wrote:<br>
>> ><br>
>> > Hello,<br>
>> ><br>
>> > Can you please tell us a little more about your test data and computer.<br>
>> > What<br>
>> ><br>
>> > kind of file system is the data on ( locale or network)? How much memory<br>
>> ><br>
>> > does the computer have? What is the size of the data? What is the native<br>
>> ><br>
>> > pixel type of the data? What are the actual timings? Does the execution<br>
>> > seem<br>
>> ><br>
>> > to be CPU or IO bound?<br>
>> ><br>
>> > One of the changes that was made to the class was to populate the<br>
>> ><br>
>> > MetaDataArray in the UpdataOutputInformation phase of the instead of the<br>
>> ><br>
>> > UpdateOutputData part. This should be just reading the headers of the<br>
>> > files<br>
>> ><br>
>> > in the series. There were several reasons this change was made. To help<br>
>> ><br>
>> > determine the cause of your slowness, lets break up the timing a little<br>
>> ><br>
>> > further.<br>
>> ><br>
>> > Could you please call:<br>
>> ><br>
>> > start timer<br>
>> ><br>
>> > reader->UpdateOutputInformation();<br>
>> ><br>
>> > lap timer<br>
>> ><br>
>> > reader->UpdateLargestPossibleRegion();<br>
>> ><br>
>> > stop timer<br>
>> ><br>
>> > And post the timing results.<br>
>> ><br>
>> > Thanks,<br>
>> ><br>
>> > Brad<br>
>> ><br>
>> > On Mar 21, 2010, at 2:52 PM, Roger Bramon Feixas wrote:<br>
>> ><br>
>> > This week we updated our ITK version from 2.8 to 3.16 and we noticed<br>
>> > the<br>
>> ><br>
>> > medical models are loading 2x slower using the 3.16 ITK version. We use<br>
>> ><br>
>> > itk::ImageSeriesReader and the problem is focused in its Update()<br>
>> > method.<br>
>> ><br>
>> > I attached a simple test program which reproduces the problem and where<br>
>> > we<br>
>> ><br>
>> > can see that the Update() method is 2 times slower using ITK 3.16 vs.<br>
>> > ITK<br>
>> ><br>
>> > 2.8.<br>
>> ><br>
>> > We compiled both versions using Visual Studio 2008 on Windows XP 32bits<br>
>> > and<br>
>> ><br>
>> > we don't known if this problem also occurs in other platforms.<br>
>> ><br>
>> > I wonder if other itk users have this same performance problem and if<br>
>> > there<br>
>> ><br>
>> > is anybody can help us in order to solve it.<br>
>> ><br>
>> > Thanks!<br>
>> ><br>
>> > Roger<br>
>> ><br>
>> ><br>
>> > ========================================================<br>
>> ><br>
>> > Bradley Lowekamp<br>
>> ><br>
>> > Lockheed Martin Contractor for<br>
>> ><br>
>> > Office of High Performance Computing and Communications<br>
>> ><br>
>> > National Library of Medicine<br>
>> ><br>
>> > <a href="mailto:blowekamp@mail.nih.gov" target="_blank">blowekamp@mail.nih.gov</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > ========================================================<br>
>> ><br>
>> > Bradley Lowekamp<br>
>> ><br>
>> > Lockheed Martin Contractor for<br>
>> ><br>
>> > Office of High Performance Computing and Communications<br>
>> ><br>
>> > National Library of Medicine<br>
>> ><br>
>> > <a href="mailto:blowekamp@mail.nih.gov" target="_blank">blowekamp@mail.nih.gov</a><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>
</blockquote></div><br><div>
<span style="border-collapse:separate;border-spacing:0px 0px;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="border-collapse:separate;border-spacing:0px 0px;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><p style="margin:0.0px 0.0px 0.0px 0.0px">
<font face="Helvetica" size="3" style="font:12.0px Helvetica">========================================================</font></p><p style="margin:0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font:12.0px Helvetica">Bradley Lowekamp<span> </span><span> </span></font></p>
<p style="margin:0.0px 0.0px 0.0px 0.0px"><font face="Arial"><span style="font-family:Arial"><span style="font-family:Arial">Lockheed Martin </span></span></font><font face="Helvetica" size="3" style="font:12.0px Helvetica">Contractor for</font></p>
<p style="margin:0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font:12.0px Helvetica">Office of High Performance Computing and Communications</font></p><p style="margin:0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font:12.0px Helvetica">National Library of Medicine<span> </span></font></p>
<p style="margin:0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font:12.0px Helvetica"><a href="mailto:blowekamp@mail.nih.gov" target="_blank">blowekamp@mail.nih.gov</a></font></p><br></span></span>
</div>
<br></div></div></div></div></blockquote></div><br></div>