relative speed of incremention syntaxes (or "i=i+1" VS "i+=1")

[Terry Reedy]

On 8/21/2011 7:17 PM, Andreas Löscher wrote:
> Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith:
>> In article<mailman.282.1313951079.27778.python-list at python.org>,
>>   Christian Heimes<lists at 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-case
>>>> 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 statement
>>> 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 for
> 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 
small ints, like bytes or less. For C, the table is simply an array of 
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 slower
> 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 = stream = POP();
> 1803	            /* fall through to PRINT_NEWLINE */

add jump to address of the code for PRINT_NEWLINE

> 1804	
> 1805	        case PRINT_NEWLINE:
>
> must be supported.

-- 
Terry Jan Reedy