Looking for info on Python's memory allocation

Alex Martelli aleax at mail.comcast.net
Tue Oct 11 12:26:59 EDT 2005


Steven D'Aprano <steve at REMOVETHIScyber.com.au> wrote:
   ...
> > s = [k for k in iterable]
> > 
> > if I know beforehand how many items iterable would possibly yield, would
> > a construct like this be faster and "use" less memory?
> > 
> > s = [0] * len(iterable)
> > for i in xrange(len(iterable)):
> >      s[i] = iterable.next()
> 
> Faster? Maybe. Only testing can tell -- but I doubt it. But as for less

Testing, of course, is trivially easy:

Helen:/tmp alex$ python -mtimeit -s'i=xrange(7)' 'L=[x for x in i]'
100000 loops, best of 3: 6.65 usec per loop

Helen:/tmp alex$ python -mtimeit -s'i=xrange(7)' 'L=list(i)'         
100000 loops, best of 3: 5.26 usec per loop

So, using list() instead of that silly list comprehension does have an
easily measurable advantage.  To check the complicated option...:

Helen:/tmp alex$ python -mtimeit -s'i=xrange(7)' '
s = [0]*7
u = iter(i)
for x in xrange(7):
  s[x] = u.next()
'
10000 loops, best of 3: 24.7 usec per loop

So, the "advantage" of all the complications is to slow down execution
by about four times -- net of all the juicy possibilities for confusion
and errors (there is no common Python type on which you can both call
len(...) AND the .next() method, for example -- a combination which
really makes no sense).

*SIMPLICITY* is the keyword here -- list(...) is by far simplest, and
almost five times faster than that baroque gyrations above...


Alex



More information about the Python-list mailing list