Steven D'Aprano wrote: >>> $ 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 >>> $ python2.4 -mtimeit 'x = range(100000); x[:] = []' >>> 100 loops, best of 3: 6.36 msec per loop >>> $ python2.4 -mtimeit 'x = range(100000); del x' >>> 100 loops, best of 3: 6.46 msec per loop >>> >>> Why the first benchmark is the slowest? I don't get it... could someone >>> test this, too? >> In the first benchmark, you need space for two lists: the old one and >> the new one; > > Er, what new list? I see only one list, x = range(100000), which is merely > created then nothing done to it. Have I missed something?
See Duncan's explanation. This code is run many times, allocating many lists. However, only two different lists exist at any point at time. A Python list consists of two memory blocks: the list proper (a few bytes), plus the "guts", i.e. a variable-sized block of pointers to the objects. del x[:] frees the guts. > I understood Felipe to be asking, why does it take longer to just create a > list, than it takes to create a list AND then do something to it? Actually, the same code (deallocation of all integers and the list blocks) appears in either case. However, in the one case it is triggered explicitly, and before the new allocation; in the other case, the allocation of the new objects occurs before the old ones are released. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
