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

[Andreas Löscher]

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). 

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 */
1804	
1805	        case PRINT_NEWLINE:

must be supported.


Bye the way:
	First line of ceval.c since at least Version 2.4
1	
2	/* Execute compiled code */
3	
4	/* XXX TO DO:
5	   XXX speed up searching for keywords by using a dictionary
6	   XXX document it!
7	   */

:-)