Take the 2-minute tour ×

So I'm having a little trouble dealing with for loops in Python - as far as I can tell, they're getting slower with time. I'm looping over a range inside of a range, and as time passes, the loop noticeably slows. This is done inside of a game engine, if it matters. Could anyone tell me what the issue is?

Here's a quick example.

for x in range(xs): # xs, ys, and zs are all pre-determined size values

     for z in range(zs):

          for y in range(ys):

              vp = [x * vs, y * vs, z * vs]

              v = Cube(vp)

The initial speed of this process is fine, but with time the loop slows. I know it's not anything else like the Rasterizer of the game engine because when the loop is done, the rest of the engine runs at 60 FPS. So what could be the problem?

EDIT: I'm using Python 3, so there is no xrange.

EDIT 2: For this example, vs is 1.0, and the predetermined size values of xs, ys, and zs are all 20.

share|improve this question
How large are your three loop parameters, xs, ys, and zs? –  John Zwinck Aug 21 '11 at 3:50
What if you comment out either of the two lines inside the loops? –  jtbandes Aug 21 '11 at 3:50
If you are using python 2.x xrange will be faster than range –  GWW Aug 21 '11 at 3:55
Sorry about that - I'll give more info. –  SolarLune Aug 21 '11 at 4:16
How are you measuring "initial speed" vs. "slows with time"? Are we talking about iterations within a single run of the shown code, or are we talking about successive runs of the shown code? If the former, how are you measuring the percentage completion of the process? –  Karl Knechtel Aug 21 '11 at 8:07
add comment

2 Answers

up vote 13 down vote accepted

This is another case of "need more information". However, Python has a standard way of constructing nested loops like this efficiently, itertools.product:

from itertools import product

for x, y, z in product(xrange(xs), xrange(zs), xrange(ys)):
    v = Cube(vp)

It doesn't require the construction of ranges every time in the inner loop. I also switched your use of range to xrange, as it's better for large ranges, although this is really irrelevant with product.

@JohnZ's question is good -- if your "predetermined size values" are very large, and especially if vs is also large, you could be constructing some large values, and it could be taking a long time for Cube to process them.

I doubt the loop itself is slowing down, but the numbers are getting larger, so your calculations might be.

share|improve this answer
vs is actually 1.0. –  SolarLune Aug 21 '11 at 4:17
Also, my 'predetermined size values' are, for this example, 20 each. –  SolarLune Aug 21 '11 at 4:18
But that's the thing that's weird - the for loop should stay at a stable speed, shouldn't it? It's definitely getting slower with time to a point... –  SolarLune Aug 21 '11 at 4:19
If it's getting slower, it's because of what you're doing in Cube, because the values are getting very large, or because of something else going on in parallel with the loop. There isn't any other explanation. Loops just don't "get slower" in Python. –  agf Aug 21 '11 at 4:22
That seemed to help some. Thanks for that! It's still slowing down with time, but I'm accessing a global dictionary that I'm appending onto, so maybe that slowdown is to be expected. –  SolarLune Aug 21 '11 at 4:25
show 2 more comments

Three things I can think of:

Memory - if you're storing all of the generated values somewhere, the loop might be slowing down because the of all the memory being used. Python has it's own memory manager, so using up lots of memory could eventually make the program slower.

Complexity of calculations - Python uses arbitrary precision numeric data types. If you are multiplying extremely large numbers together (especially floats) the program will slow down. It really depends on how large these values get.

Cube - It could be a bug in the Cube code (although I'm sure it's probably just as simple as it sounds).

share|improve this answer
add comment

Your Answer


