New internal string format in 3.3

Chris Angelico rosuav at gmail.com
Sun Aug 19 17:50:49 EDT 2012


On Mon, Aug 20, 2012 at 4:09 AM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> On 19/08/2012 18:51, wxjmfauth at 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



More information about the Python-list mailing list