<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><span></span></div><div><br class="webkit-block-placeholder"></div><div><br><div><div>On May 13, 2008, at 6:58 AM, David Cole wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Would you happen to be measuring these results with a Debug build using the Microsoft compiler? Or is it some other config?<br><br>If Debug/Microsoft, try the Release build... Allocations are tracked by the Microsoft runtime libraries in Debug builds and they have to do some tracking on every delete/free to ensure accurate leak reports.<br> <br>If something else, feel free to ignore this email entirely.<br><br><br>:-)<br>David<br><br><br><div class="gmail_quote">On Tue, May 13, 2008 at 9:47 AM, Hank Childs <<a href="mailto:childs3@llnl.gov">childs3@llnl.gov</a>> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> Hi Berk & Brad,<br> <br> Thanks very much for your responses; your interest is much appreciated.<br> <br> To answer one of Brad's question, I am having a problem reproducing the problem with a minimal test program, which probably means something.  I will continue working on this.<br> <br> I got interested in the garbage collector because I was doing "poor man's profiling" (see footnote [1] below for more explanation) and I kept observing that garbage collection was dominating.<br> <br> To answer Berk's question, yes, I was unclear.  Here is the general setup:  We are very memory conscious, so we dereference the inputs to a filter after the filter has executed (see footnote [2] below for more explanation).  So:<br> <br> for ( 20000 )<br>   filt->SetInput(input[i]);<br>   filt->Update();<br>   output[i] = filt->GetOutput()->NewInstance();<br>   output[i]->ShallowCopy(filt->GetOutput());<br> <br> for (20000)<br>   input[i]->Delete();<br> <br> I found that the Delete() calls were taking a huge amount of time.  So I wrapped them with:<br> <br> vtkGarbageCollector::Push()<br> for (20000)<br>   input[i]->Delete();<br> vtkGarbageCollector::Pop()<br> <br> and found that that improved the situation (supporting Brad's claim that it should be faster), but it was still taking a long time.  I have also found variation in the run times, meaning that my OS may have a role here too, likely in terms of lots of small allocations and deallocations.<br> <br> I don't think that I was very clear in my last email, so I want to try again.  My only evidence against garbage collection is that my poor man's profiling shows that my program is doing garbage collection the majority of the time.<br> <br> Instead of raising the garbage collection issue, the tack I should have taken is to ask why it was taking 47s to delete the output, when it took only 20s to create it, as well as executing the filters.  Of course, I would greatly help my cause here if I could get a simple reproducer that people could sink their teeth into.  So, again, I'll continue pursuing that...<br> <br> Best,<br> Hank<br> <br> [1] poor man's profiling means connecting with a debugger regularly and seeing where the work was happening ... I have had problems getting profilers to run on big software projects and I find this to be somewhat effective.<br> <br> [2] As you all know, there is a tradeoff between reusing cached results (what VTK does by default) and keeping memory low (what I am doing manually).  Of course, VTK does a good job of minimizing the overhead for reusing cached results by often sharing references between input and output.  Regardless, there is often memory associated with the input that is not needed in the output.  For what I'm working on, harvesting that memory is worthwhile.  Also, I mitigate the loss of reusing cached results somewhat by keeping a cache for all I/O (... and I have found that I/O is often the bottleneck).<div> <div></div><div class="Wj3C7c"><br> <br> On May 13, 2008, at 6:15 AM, Berk Geveci wrote:<br> <br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Hi Hank,<br> <br> Where is the big loop over 20000 items happening? Around the Push/Pop<br> or inside them?<br> <br> -berk<br> <br> On Mon, May 12, 2008 at 6:35 PM, Hank Childs <<a href="mailto:childs3@llnl.gov" target="_blank">childs3@llnl.gov</a>> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <br>  Hello VTK Developers!<br> <br>  I am running in serial and am setting up about 20000 pipelines on my serial<br> process for about 20000 chunks of data.<br> <br>  The runtime has gotten disproportionately large with the large number of<br> chunks and I believe that garbage collection is at least partly to blame.<br> <br>  For example, if I:<br>  1) call vtkGarbageCollector::DeferredCollectionPush()<br>  2) execute three filters (filters that find external faces and remove ghost<br> data) and,<br>  3) call vtkGarbageCollector::DeferredCollectionPop()<br> <br>  then: the three filters take about 20s total and the DeferredCollectionPop<br> takes about 47s.<br> <br>  One conclusion that I drew from the fast execution of the three filters, is<br> that iterating through the data is relatively quickly.  Restated, I ruled<br> out thrashing through memory as the reason the garbage collector is taking<br> 47s.<br> <br>  Also, I should disclose that I am managing the execution manually.  The<br> best way to describe it would be that I have one instance of filter A, one<br> instance of filter B, and one instance of filter C and that I route all 20K<br> data sets through filter A, to make 20K new data sets, then route those 20K<br> new data sets through B, and so on.  Also, I know that the alternative is to<br> call "Update()" 20K times, one for each chunk, but I'd prefer not to go down<br> that route, for reasons I can explain if necessary.<br> <br>  So: can anyone point me to some words of wisdom about a way to manage my<br> data objects so that garbage collection is faster?<br> <br>  Best regards,<br>  Hank_______________________________________________<br>  vtk-developers mailing list<br>  <a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a><br>  <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br> <br> </blockquote></blockquote> <br> _______________________________________________<br> vtk-developers mailing list<br> <a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a><br> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br> </div></div></blockquote></div><br></blockquote></div><br></div></body></html>