Python Speed

[Terry Reedy]

On 2/27/2013 7:15 PM, Ian Kelly wrote:
> On Wed, Feb 27, 2013 at 3:24 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>>> Py33
>>>>>> timeit.repeat("{1:'abc需'}")
>>> [0.2573893570572636, 0.24261832285651508, 0.24259548003601594]
>>
>> On my win system, I get a lower time for this:
>> [0.16579443757208878, 0.1475787649924598, 0.14970205670637426]
>>
>>> Py323
>>> timeit.repeat("{1:'abc需'}")
>>> [0.11000708521282831, 0.0994753634273593, 0.09901023634051853]
>>
>> While I get the same time for 3.2.3.
>> [0.11759353304428544, 0.09482448029000068, 0.09532802044164157]
>>
>> It seems that something about Jim's machine does not like 3.3.
>> *nix will probably see even less of a difference. Times are in microseconds,
>> so few programs will ever notice the difference.
>
> Running the same tests in IDLE on my Windows XP laptop, I see similar
> results to what jmf reports.

Whereas I run win 7 on a pentium i7 desktop. For this, I suspect the 
processor difference more than the OS. To really investigate, one should 
separately time string creation from dict creation with a pre-built string.

repeat('pass')  # .013 to .02 on both
repeat("'abc需'") # same, untimeable
repeat("'abc需'*10") # .12 versus .14 on 3.2 and 3.3
repeat("{1:s}", "s='abc需'")  # .10 versus .14

There is a problem with timer overhead for sub-microsecond operations. 
In interactive use, the code is compiled within a function that gets 
called. The string 'abc需' should be stored as a constant in the code 
object. To force repeated string operation, one should either time from 
command line or do an operation, as with the example above. I notice 
that the first of 3 times is almost always higher for some reason.

> But from what Christian posted, it
> sounds like this regression may have more to do with PEP 412 than PEP
> 393.

That change traded a space saving and for a small initial time cost.
Christian also showed that initial cost has since been cut. There may be 
more internal dict tweaks before 3.4.

-- 
Terry Jan Reedy