relative speed of incremention syntaxes (or "i=i+1" VS "i+=1")
andreas.loescher at s2005.tu-chemnitz.de
Mon Aug 22 01:17:14 CEST 2011
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
1802 w = stream = POP();
1803 /* fall through to PRINT_NEWLINE */
1805 case PRINT_NEWLINE:
must be supported.
Bye the way:
First line of ceval.c since at least Version 2.4
2 /* Execute compiled code */
4 /* XXX TO DO:
5 XXX speed up searching for keywords by using a dictionary
6 XXX document it!
More information about the Python-list