Home Original page

list.clear() missing?!?

Dan Christensen jdc at uwo.ca
Wed Apr 12 22:00:10 EDT 2006 
Raymond Hettinger <python at rcn.com> writes:

> Felipe Almeida Lessa writes:
> 
> > I love benchmarks, so as I was testing the options, I saw something very
> > strange:
> >
> > $ python2.4 -mtimeit 'x = range(100000); '
> > 100 loops, best of 3: 6.7 msec per loop
> > $ python2.4 -mtimeit 'x = range(100000); del x[:]'
> > 100 loops, best of 3: 6.35 msec per loop
> >
> > Why the first benchmark is the slowest? I don't get it... could someone
> > test this, too?
>
> It is an effect of the memory allocator and fragmentation.  The first
> builds up a list with increasingly larger sizes.  

I don't see what you mean by this.  There are many lists all of
the same size.  Do you mean some list internal to the memory
allocator? 

> It periodically
> cannot grow in-place because something is in the way (some other
> object) so it needs to move its current entries to another, larger
> block and grow from there.  In contrast, the other entries are reusing
> a the previously cleared out large block.
>
> Just for grins, replace the first with"
>   'x=None; x=range(100000)'
> The assignment to None frees the reference to the previous list and
> allows it to be cleared so that its space is immediately available to
> the new list being formed by range().

It's true that this runs at the same speed as the del variants on my
machine.  That's not too surprising to me, but I still don't
understand why the del variants are more than 5% faster than the first
version.

Once this is understood, is it something that could be optimized?
It's pretty common to rebind a variable to a new value, and if
this could be improved 5%, that would be cool.  But maybe it
wouldn't affect anything other than such micro benchmarks.

Dan
More information about the Python-list mailing list