<span id="goog_1636432608"></span><span id="goog_1636432609"></span><a href="/"></a>Thank you all for the comments and suggestions.<div><br></div><div>First off, I would like to say that I entirely agree with people's suggestions about lack of objectiveness in the test design, and the caveat about optimizing early. The main reason we put together the Python version of the benchmark was as a quick "sanity check" to make sure that there are no major show-stoppers before we began work on the library. We also wanted to put together something to show other people who are firmly in the IDL camp that this is a viable option.</div>
<div><br></div><div>We did in fact put together another short test-suite (<a href="https://github.com/sunpy/sunpy/tree/master/benchmarks">test_testr.py & time_testr.pro</a>) which consists of operations that would are frequently used by us, but it also is testing a very small portion of the kinds of things our library will eventually do.</div>
<div><br></div><div>That said, I made a few small changes to the original benchmark, based on people's feedback, and put together a new plot.</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
<div><br></div><div>The changes made include:</div><div><br></div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>1. Using xrange instead of range</div>
</div><div><div>2. Using uniform filter instead of median filter</div></div><div><div>3. Fixed a typo for tests 2 & 3 which resulted in slower Python results</div></div><div><br></div></blockquote>Again, note that some of the tests are testing non-numpy functionality. Several of the results still stand out, <meta http-equiv="content-type" content="text/html; charset=utf-8"> but overall the results are much more reasonable than before.<div>
<br><div>Cheers,</div><div>Keith</div></div>