Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1")
Date: Sun, 21 Aug 2011 19:38:22 -0400
References: <4e513ceb$0$23863$e4fe514c@news2.news.xs4all.nl> <1313947658.3424.3.camel@thegeorge> <mailman.282.1313951079.27778.python-list@python.org> <roy-D16F14.14525021082011@news.panix.com> <1313968634.3135.14.camel@thegeorge>
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:6.0) Gecko/20110812 Thunderbird/6.0
In-Reply-To: <1313968634.3135.14.camel@thegeorge>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.291.1313969950.27778.python-list@python.org>
Lines: 59
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:11971

On 8/21/2011 7:17 PM, Andreas L=C3=B6scher wrote:
> Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith:
>> In article<mailman.282.1313951079.27778.python-list@python.org>,
>>   Christian Heimes<lists@cheimes.de>  wrote:
>>
>>> Am 21.08.2011 19:27, schrieb Andreas Lscher:
>>>> As for using Integers, the first case (line 1319 and 1535) are true =
and
>>>> there is no difference in Code. However, Python uses a huge switch-c=
ase
>>>> construct to execute it's opcodes and INPLACE_ADD cames after
>>>> BINARY_ADD, hence the difference in speed.
>>>
>>> I don't think that's the reason. Modern compiles turn a switch statem=
ent
>>> into a jump or branch table rather than a linear search like chained
>>> elif statements.
>>
>> This is true even for very small values of "modern".  I remember the
>> Unix v6 C compiler (circa 1977) was able to do this.
>
> What is the difference in speed between a jump table that is searched
> from top to bottom in comparison to an ordinary if-then-elif...? The
> difference can only be in the search algorithm regarding the table.
> Without optimization (linear search) both are the same. If the compiler=

> applies some magic the difference can be relevant (linear complexity fo=
r
> if-then-elif... and O(1) if you would use a dictionary).

A jump or branch table is applicable when the case value values are all=20
small ints, like bytes or less. For C, the table is simply an array of=20
pointers (addressess, with entries for unused byte codes would be a void =

pointer). Hence, O(1) access.
https://secure.wikimedia.org/wikipedia/en/wiki/Jump_table

> Hence the executed code for integers is the same, there must be a slowe=
r
> path to the code of BINARY_ADD than to INPLACE_ADD.
>
> How would such an jump table work to behave the same liek a
> switch-case-statement? Beware, that things like
>
>         case PRINT_NEWLINE_TO:
> 1802	            w =3D stream =3D POP();
> 1803	            /* fall through to PRINT_NEWLINE */

add jump to address of the code for PRINT_NEWLINE

> 1804=09
> 1805	        case PRINT_NEWLINE:
>
> must be supported.

--=20
Terry Jan Reedy