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

[Andreas Löscher]

Am Sonntag, den 21.08.2011, 19:38 -0400 schrieb 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.
> 

:-) too easy or too late 
thanks