The CPython bytecode difference between iteration and looping

August 12, 2012

Because I feel like it, today I'm going to show you the difference in CPython bytecodes between the two variants of 'repeat N times' that I talked about in my entry on the periodic strangeness of idiomatic Python. Both are going to be in functions (because that's the common case of where Python code is).

First, the iteration version:

def iter(max):
  for _ in range(max):

The core bytecode of the function looks like the following (note that I have simplified the actual bytecode disassembly to make it easier to read):

 1   LOAD_GLOBAL   range
 2   LOAD_FAST     max
 5   FOR_ITER      (to 8)
 6   STORE_FAST    _
 7   JUMP_ABSOLUTE (to 5)

Bytecodes 1 through 3 are the initial setup, ie the call to range(max) and turning the result into an iterator. The actual for loop over the iterator is three bytecode instructions, 5, 6, and 7; if the loop ran actual code it would appear between 6 and 7.

(When reading the bytecode, it helps to know that CPython bytecode is stack based; arguments to operations are put on the stack (eg, by various LOAD instructions) and then popped off as part of other operations (eg by STORE instructions). The FOR_ITER bytecode includes information about where to resume execution when the iterator is exhausted, in this case at bytecode 8.)

The explicit loop version is:

def loop(max):
  i = 0
  while i < max:
    i += 1

There is a bunch more bytecode here:

 0   LOAD_CONST    0
 1   STORE_FAST    i
 3   LOAD_FAST     i
 4   LOAD_FAST     max
 5   COMPARE_OP    <
 6   POP_JUMP_IF_FALSE (to 12)
 7   LOAD_FAST     i
 8   LOAD_CONST    1
10   STORE_FAST    i
11   JUMP_ABSOLUTE (to 3)

Setup takes only two bytecodes, to initialize i to 0. But the actual loop involves much more bytecodes; four bytecodes (3-6) are necessary to handle the loop condition and it takes another four (7-10) to increment i (and then a final bytecode, 11, to close the loop). So this code is processing 9 bytecodes every time through the loop, plus it's doing a bunch more stack manipulation than the iteration loop.

Now, you might sensibly ask if this difference in how many bytecodes there are makes any real performance difference; after all, an efficient interpreter can run bytecodes pretty fast. The short answer is that it does; on a 64-bit Linux machine with Python 2.7.3, the loop based version is around 3.4 times slower than the iteration based version. I can make the difference even bigger by changing range() to xrange() in the iterator version, which avoids a chunk of overhead.

(I timed with a max of 10000, which artificially lowers the setup overhead and increases the actual loop overhead.)

Does this performance difference matter? Probably not. In real code you're likely to be looping only for a relatively short number of iterations and the real work you're doing on each iteration will probably dwarf the loop overhead.

PS: due to a comment by David B on the original entry, the most efficient way to do this is:

from itertools import repeat
def itools(max):
  for _ in repeat(None, max):

This beats even the xrange() based version, and not by a little bit. Why it is better is an interesting thing to think about.

Written on 12 August 2012.
« How not to write kernel messages
A nice illustration of the cost of creating and destroying objects in Python »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Aug 12 00:54:41 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.