On 2/27/2013 7:15 PM, Ian Kelly wrote:
On Wed, Feb 27, 2013 at 3:24 PM, Terry Reedy <tjre...@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
--
http://mail.python.org/mailman/listinfo/python-list
