[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

stupid/style/list question

Giampaolo Rodola'

1/8/2008 3:34:00 PM

I was wondering...
To flush a list it is better doing "del mylist[:]" or "mylist = []"?
Is there a preferred way? If yes, why?
7 Answers

Fredrik Lundh

1/8/2008 3:45:00 PM

0

Giampaolo Rodola' wrote:

> To flush a list it is better doing "del mylist[:]" or "mylist = []"?
> Is there a preferred way? If yes, why?

The latter creates a new list object, the former modifies an existing
list in place.

The latter is shorter, reads better, and is probably a bit faster in
most cases.

The former should be used when it's important to clear a specific list
object (e.g. if there are multiple references to the list).

</F>

Tim Chase

1/8/2008 3:53:00 PM

0

> To flush a list it is better doing "del mylist[:]" or "mylist = []"?
> Is there a preferred way? If yes, why?

It depends on what you want. The former modifies the list
in-place while the latter just reassigns the name "mylist" to
point to a new list within the local scope as demonstrated by this:

def d1(mylist):
"Delete in place"
del mylist[:]

def d2(mylist):
"Just reassign"
mylist = []

for test in [d1,d2]:
input = [1,2,3]
print 'Before:', input
print test.__doc__
test(input)
print 'After:', input
print

As performance goes, you'd have to test it, but I suspect it's
not a glaring difference, and would suspect that the latter is a
bit faster.


-tkc

Giampaolo Rodola'

1/8/2008 7:05:00 PM

0

On 8 Gen, 16:45, Fredrik Lundh <fred...@pythonware.com> wrote:
> Giampaolo Rodola' wrote:
> > To flush a list it is better doing "del mylist[:]" or "mylist = []"?
> > Is there a preferred way? If yes, why?
>
> The latter creates a new list object, the former modifies an existing
> list in place.
>
> The latter is shorter, reads better, and is probably a bit faster in
> most cases.
>
> The former should be used when it's important to clear a specific list
> object (e.g. if there are multiple references to the list).
>
> </F>

I'm going to use the latter one, thanks.

Raymond Hettinger

1/8/2008 10:40:00 PM

0

On Jan 8, 7:34 am, "Giampaolo Rodola'" <gne...@gmail.com> wrote:
> I was wondering...
> To flush a list it is better doing "del mylist[:]" or "mylist = []"?
> Is there a preferred way? If yes, why?


To empty an existing list without replacing it, the choices
are "del mylist[:]" and "mylist[:] = []". Of the two, I
prefer the former because it reads more explicity (delete
all of the items from the list"). In terms of performance,
they are basically the same.

To replace a list, "mylist = []" is the way to go. This is
an affirmative statement that you are creating a new list.

Raymond

Duncan Booth

1/9/2008 8:59:00 AM

0

Fredrik Lundh <fredrik@pythonware.com> wrote:

> Giampaolo Rodola' wrote:
>
>> To flush a list it is better doing "del mylist[:]" or "mylist = []"?
>> Is there a preferred way? If yes, why?
>
> The latter creates a new list object, the former modifies an existing
> list in place.
>
> The latter is shorter, reads better, and is probably a bit faster in
> most cases.
>
> The former should be used when it's important to clear a specific list
> object (e.g. if there are multiple references to the list).

I tried to measure this with timeit, and it looks like the 'del' is
actually quite a bit faster (which I find suprising).

C:\Python25\Lib>timeit.py -s "lista=range(10000)" "mylist=list(lista)"
10000 loops, best of 3: 81.1 usec per loop

C:\Python25\Lib>timeit.py -s "lista=range(10000)" "mylist=list(lista)"
"del mylist[:]"
10000 loops, best of 3: 61.7 usec per loop

C:\Python25\Lib>timeit.py -s "lista=range(10000)" "mylist=list(lista)"
"mylist=[]"
10000 loops, best of 3: 80.9 usec per loop


In the first test the local variable 'mylist' is simply allowed to go
out of scope, so the list is destroyed as its reference count drops to
0.

In the third case again the list is destroyed when no longer referenced,
but an empty list is also created and destroyed. Evidently the empty
list takes virtually no time to process compared with the long list.

The second case clears the list before destroying it, and appears to be
significantly faster.

Increasing the list length by a factor of 10 and it becomes clear that
not only is #2 always fastest, but #3 always comes in second. Only when
the lists are quite short (e.g. 10 elements) does #1 win (and even at 10
elements #2 beats #3).

Unless I've missed something, it looks like there may be an avoidable
bottleneck in the list code: whatever the slice delete is doing should
also be done by the deletion code (at least if the list is longer than
some minimum length).

The most obvious thing I can see is that list_dealloc:

if (op->ob_item != NULL) {
/* Do it backwards, for Christian Tismer.
There's a simple test case where somehow this reduces
thrashing when a *very* large list is created and
immediately deleted. */
i = Py_Size(op);
while (--i >= 0) {
Py_XDECREF(op->ob_item[i]);
}
PyMem_FREE(op->ob_item);
}


would be better written as a copy of (or even call to) list_clear which
picks up op->ob_item once instead of every time through the loop.

Bearophile

1/9/2008 12:43:00 PM

0

Duncan Booth:
> I tried to measure this with timeit, and it looks like the 'del' is
> actually quite a bit faster (which I find suprising).

Yes, it was usually faster in my benchmarks too. Something similar is
true for dicts too. I think such timings are influenced a lot by the
garbage collector.

Bye,
bearophile

Duncan Booth

1/9/2008 3:54:00 PM

0

bearophileHUGS@lycos.com wrote:

> Duncan Booth:
>> I tried to measure this with timeit, and it looks like the 'del' is
>> actually quite a bit faster (which I find suprising).
>
> Yes, it was usually faster in my benchmarks too. Something similar is
> true for dicts too. I think such timings are influenced a lot by the
> garbage collector.
>
That may come into it, but I made the obvious change I mentioned (to avoid
dereferncing a pointer every time through the loop) and got about an 8%
speed-up on my test. I don't think that explains all of the speed
difference though, so the garbage collector may come into it too: I'll see
if I can do some more experimentation before submitting a patch.