Python Speed
Terry Reedy
tjreedy at udel.edu
Wed Feb 27 21:11:25 EST 2013
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
More information about the Python-list
mailing list