<div dir="ltr">In general, we do want to make sure the tests produce "correct" results and make sure there are no regressions. By having the Release build run a proper set of iterations, the developer can verify the correctness.<div>
<br></div><div style>That said, using a lower resolution input dataset could probably help most the these tests and the release/debug times would both be reduced.</div><div style><br></div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Fri, Aug 2, 2013 at 10:49 AM, David Cole <span dir="ltr"><<a href="mailto:dlrdave@aol.com" target="_blank">dlrdave@aol.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr" style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif;font-size:12pt">
<div class="im"><div> </div><div dir="ltr">> I think it is OK to drop the iterations in the Debug tests. We are still exercising the code. If we</div><div dir="ltr">> need alternate baselines, we will still catch exceptions. This will also allow more valgrind tests</div>
<div dir="ltr">> to run to completion.</div><div dir="ltr"> </div><div dir="ltr"> </div></div><div dir="ltr">Ha ha. Ironic. I just noticed the slowest 3 tests have the word “Fast” in the test name... Perhaps we should at the very least consider a rename. <span style="font-family:"Segoe UI Symbol","Apple Color Emoji"">😊</span></div>
<div dir="ltr"> </div><div dir="ltr">If it’s ok to drop the iterations in the Debug tests, then why not drop the iterations in the Release tests, too? There is something to be said for the “same” code being run for the test in both Debug and Release. If it’s not the same, then I should definitely be able to tell just by glancing at the source code for a test that there are Debug/non-Debug differences...</div>
<div dir="ltr"> </div><div dir="ltr">I would say each individual test should be able to run in *seconds*, not minutes or hours. Ideally, less than a second, but I realize that’s overly ambitious with some ITK code.</div><div dir="ltr">
</div><div dir="ltr">However, for the main purpose I have in mind here, namely reducing the time burden on my volunteer machine, I would be absolutely *ecstatic* if all of the 20 tests I listed in the original email were able to run in under 4 or 5 minutes each.</div>
<div dir="ltr"> </div><div dir="ltr">Let me know if I can help out in some additional way (beyond just continuing to submit the build to CDash...)</div><div dir="ltr"> </div><div dir="ltr"> </div><div dir="ltr">Thanks for the discussion, I appreciate it</div>
<span class="HOEnZb"><font color="#888888"><div dir="ltr">D</div><div dir="ltr"> </div>
</font></span></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Unpaid intern in BillsBasement at noware dot com<br>
</div>