Blackbird <[EMAIL PROTECTED]> wrote: ... > >> for i in range(10): > >> <some code that depends on i> ... > > Yup, and if you are tuning a piece of code to the wall, you should > > time it and possibly care. Likely you are not, and the timing makes > > no difference. Someday, range will behave like xrange automagically, ... > Thanks. Yes, this will be a problem for iterations in the order of 10**5 and > upwards only, and those are rare in most applications. So my question was
And not crucial when they happen, mostly: helen:~ alex$ python -mtimeit -s'x=10**5' 'for i in range(x): j=i*i' 10 loops, best of 3: 102 msec per loop helen:~ alex$ python -mtimeit -s'x=10**5' 'for i in xrange(x): j=i*i' 10 loops, best of 3: 80.9 msec per loop a 20% difference (for a very lightweight loop body), while measurable, will matter at all only in the hottest of hotspots, the narrowest of bottlenecks. Anyway, do learn about -mtimeit, it's cool indeed for such performance measurements. > more motivated by a general curiosity about the inner workings of the Python > interpreter, and I sort of understand why advanced optimization on an > instruction set like bytecode would be difficult. And in the mean time, I Python deliberately avoids all sorts of optimizations, including obvious ones such as constant hoisting -- the idea being that when you need something hoisted, you can hoist it yourself, and meanwhile by knowing that the compiler is dirt-simple and literal-minded you avoid all kinds of risks connected to optimizer bugs or misunderstandings thereof. Alex -- http://mail.python.org/mailman/listinfo/python-list
