API/C memory mananegemnt problem

[Alex Martelli]

<plahey at alumni.caltech.edu> wrote:

> Sorry for responding to my own post.
> 
> I think I understand the original statement now.  What you are really
> saying is that there is a pool of Python float objects (which can, at
> different times, wrap different values) which can grow but never
> decrease in size.  So the memory held by this pool is dictated by the
> maximum number of floats that have ever been simultaneously active
> (accessible).
> 
> The same goes for integers.  All the more reason to avoid range(.) and
> use xrange(.).

Uh? The integers produced as you loop over xrange will be just immortal
as those that get into the list built by range, so why is int
immortality any reason to use one over the other?

If you know you're probably not going to loop over ALL the range or
xrange, sure, but that's relatively rare -- and, when it does occur,
xrange is seriously preferable:

helen:~ alex$ python -mtimeit 'for x in range(100): pass'
100000 loops, best of 3: 15.9 usec per loop

helen:~ alex$ python -mtimeit 'for x in xrange(100): pass'
100000 loops, best of 3: 12.2 usec per loop

helen:~ alex$ python -mtimeit 'for x in range(100): break'
100000 loops, best of 3: 7.57 usec per loop

helen:~ alex$ python -mtimeit 'for x in xrange(100): break'
1000000 loops, best of 3: 1.5 usec per loop

The immediate break only halves the time requirements of the range-based
loop, but it slashes by 8 times those of the xrange-based one -- now
THAT is big enough to matter, as opposed to the 20% or so difference in
overhead when you're always looping all the way, which is unlikely to
make an important difference in overall application speed.


Alex