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