<br><div class="gmail_quote">On Mon, Apr 4, 2011 at 7:45 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve%2Bcomp.lang.python@pearwood.info">steve+comp.lang.python@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I'm writing some tests to check for performance regressions (i.e. you<br>
change a function, and it becomes much slower) and I was hoping for some<br>
guidelines or hints.<br>
<br>
This is what I have come up with so far:<br>
<br>
<br>
* The disclaimers about timing code snippets that can be found in the<br>
timeit module apply. If possible, use timeit rather than roll-you-own<br>
timers.<br>
<br>
* Put performance tests in a separate test suite, because they're<br>
logically independent of regression tests and functional tests, and<br>
therefore you might not want to run them all the time.<br>
<br>
* Never compare the speed of a function to some fixed amount of time,<br>
since that will depend on the hardware you are running on, but compare it<br>
relative to some other function's running time. E.g.:<br>
<br>
# Don't do this:<br>
time_taken = Timer(my_func).timeit()  # or similar<br>
assert time_taken <= 10<br>
    # This is bad, since the test is hardware dependent, and a change<br>
    # in environment may cause this to fail even if the function<br>
    # hasn't changed.<br>
<br>
# Instead do this:<br>
time_taken = Timer(my_func).timeit()<br>
baseline = Timer(simple_func).timeit()<br>
assert time_taken <= 2*baseline<br>
    # my_func shouldn't be more than twice as expensive as simple_func<br>
    # no matter how fast or slow they are in absolute terms.<br>
<br>
<br>
Any other lessons or hints I should know?<br>
<br>
If it helps, my code will be targeting Python 3.1, and I'm using a<br>
combination of doctest and unittest for the tests.<br><font color="#888888"><a href="http://mail.python.org/mailman/listinfo/python-list" target="_blank"></a></font></blockquote><div><br>Interesting topic.<br><br>I suppose you could compare to a pystone result times some constant.  <a href="http://code.activestate.com/recipes/440700-performance-testing-with-a-pystone-measurement-dec/">http://code.activestate.com/recipes/440700-performance-testing-with-a-pystone-measurement-dec/</a><br>
<br>FWIW, doctest is a cool idea, but it kind of limits your options, as it enshrines little details that'll cause your tests to fail if you move to Pypy or Jython or IronPython or whatever.<br><br></div></div>I tend to lump my performance-related tests in with my other tests, but perhaps this is a personal preference thing.  So of course, I try to keep my performance tests brief - sometimes with the non-default option of doing a more thorough test.  Because the time to know that things have suddenly slowed way down is during development, not right before a new release.<br>
<br>