To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Python Speed
Date: Wed, 27 Feb 2013 21:11:25 -0500
References: <kgm12e$vus$1@ger.gmane.org> <CALwzidnP03kuTMPw_wnknG_CvbuWBHkR2JWZ7Xs3pVyZHntWCg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
In-Reply-To: <CALwzidnP03kuTMPw_wnknG_CvbuWBHkR2JWZ7Xs3pVyZHntWCg@mail.gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2633.1362017506.2939.python-list@python.org>
Lines: 56
NNTP-Posting-Host: 2001:888:2000:d::a6
Path: csiph.com!usenet.pasdenom.info!news.stben.net!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Xref: csiph.com comp.lang.python:40095

On 2/27/2013 7:15 PM, Ian Kelly wrote:
> On Wed, Feb 27, 2013 at 3:24 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>>> Py33
>>>>>> timeit.repeat("{1:'abc=C3=A9=C5=93=E2=82=AC'}")
>>> [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=C3=A9=C5=93=E2=82=AC'}")
>>> [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 microse=
conds,
>> 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=20
processor difference more than the OS. To really investigate, one should =

separately time string creation from dict creation with a pre-built strin=
g.

repeat('pass')  # .013 to .02 on both
repeat("'abc=C3=A9=C5=93=E2=82=AC'") # same, untimeable
repeat("'abc=C3=A9=C5=93=E2=82=AC'*10") # .12 versus .14 on 3.2 and 3.3
repeat("{1:s}", "s=3D'abc=C3=A9=C5=93=E2=82=AC'")  # .10 versus .14

There is a problem with timer overhead for sub-microsecond operations.=20
In interactive use, the code is compiled within a function that gets=20
called. The string 'abc=C3=A9=C5=93=E2=82=AC' should be stored as a const=
ant in the code=20
object. To force repeated string operation, one should either time from=20
command line or do an operation, as with the example above. I notice=20
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.

--=20
Terry Jan Reedy