On Mon, Aug 20, 2012 at 4:09 AM, Mark Lawrence <breamore...@yahoo.co.uk> wrote: > On 19/08/2012 18:51, wxjmfa...@gmail.com wrote: >> >> Just for the story. >> >> Five minutes after a closed my interactive interpreters windows, >> the day I tested this stuff. I though: >> "Too bad I did not noted the extremely bad cases I found, I'm pretty >> sure, this problem will arrive on the table". > > How convenient.
Not really. Even if he HAD copied-and-pasted those worst-cases, it'd prove nothing. Maybe his system just chose to glitch right then. It's always possible to find statistical outliers that take way way longer than everything else. Watch this. Python 3.2 on Windows is optimized for adding 1 to numbers. C:\Documents and Settings\M>\python32\python -m timeit -r 1 "a=1+1" 10000000 loops, best of 1: 0.0654 usec per loop C:\Documents and Settings\M>\python32\python -m timeit -r 1 "a=1+1" 10000000 loops, best of 1: 0.0654 usec per loop C:\Documents and Settings\M>\python32\python -m timeit -r 1 "a=1+1" 10000000 loops, best of 1: 0.0654 usec per loop C:\Documents and Settings\M>\python32\python -m timeit -r 1 "a=1+2" 10000000 loops, best of 1: 0.0711 usec per loop Now, as long as I don't tell you that during the last test I had quite a few other processes running, including VLC playing a movie and two Python processes running "while True: pass", this will look like a significant performance difference. So now, I'm justified in complaining about how suboptimal Python is when adding 2 to a number, which I can assure you is a VERY common case. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
