464,331 Members | 1,060 Online
Need help? Post your question and get tips & solutions from a community of 464,331 IT Pros & Developers. It's quick & easy.

List Performance

 P: n/a If I happen to have a list that contains over 50,000 items, will the size of the list severely impact the performance of appending to the list? Jun 30 '08 #1
9 Replies

 P: n/a Ampedesign wrote: If I happen to have a list that contains over 50,000 items, will the size of the list severely impact the performance of appending to the list? No. \$ python -m timeit -n20000 -s"items = []" "items.append(42)" 20000 loops, best of 3: 0.554 usec per loop \$ python -m timeit -n20000 -s"items = [42]*10**6" "items.append(42)" 20000 loops, best of 3: 0.529 usec per loop http://wiki.python.org/moin/TimeComplexity Peter Jun 30 '08 #2

 P: n/a Le Monday 30 June 2008 09:23:46 Peter Otten, vous avez écrit*: Ampedesign wrote: If I happen to have a list that contains over 50,000 items, will the size of the list severely impact the performance of appending to the list? No. \$ python -m timeit -n20000 -s"items = []" "items.append(42)" 20000 loops, best of 3: 0.554 usec per loop \$ python -m timeit -n20000 -s"items = [42]*10**6" "items.append(42)" 20000 loops, best of 3: 0.529 usec per loop But it surely could, if the box happens to be out of memory and begin to swap, while it's not, of course, an issue with python lists... -- _____________ Maric Michaud Jun 30 '08 #3

 P: n/a Peter Otten wrote: Ampedesign wrote: >If I happen to have a list that contains over 50,000 items, will thesize of the list severely impact the performance of appending to thelist? No. \$ python -m timeit -n20000 -s"items = []" "items.append(42)" 20000 loops, best of 3: 0.554 usec per loop \$ python -m timeit -n20000 -s"items = [42]*10**6" "items.append(42)" 20000 loops, best of 3: 0.529 usec per loop http://wiki.python.org/moin/TimeComplexity Peter Peter, So its actually faster to append to a long list than an empty one? That certainly would not have been intuitively obvious now would it? -Larry Jun 30 '08 #4

 P: n/a Larry Bates wrote: Peter Otten wrote: >Ampedesign wrote: >>If I happen to have a list that contains over 50,000 items, will thesize of the list severely impact the performance of appending to thelist? No.\$ python -m timeit -n20000 -s"items = []" "items.append(42)"20000 loops, best of 3: 0.554 usec per loop\$ python -m timeit -n20000 -s"items = [42]*10**6" "items.append(42)"20000 loops, best of 3: 0.529 usec per loophttp://wiki.python.org/moin/TimeComplexityPeter Peter, So its actually faster to append to a long list than an empty one? That certainly would not have been intuitively obvious now would it? You shouldn't blindly trust the numbers. Here's what happens if I repeat the measurements a few times: \$ python -m timeit -n20000 -s"items = []" "items.append(42)" 20000 loops, best of 3: 0.531 usec per loop \$ python -m timeit -n20000 -s"items = []" "items.append(42)" 20000 loops, best of 3: 0.511 usec per loop \$ python -m timeit -n20000 -s"items = []" "items.append(42)" 20000 loops, best of 3: 0.512 usec per loop \$ python -m timeit -n20000 -s"items = []" "items.append(42)" 20000 loops, best of 3: 0.51 usec per loop \$ python -m timeit -n20000 -s"items = []" "items.append(42)" 20000 loops, best of 3: 0.514 usec per loop \$ python -m timeit -n20000 -s"items = [42]*10**6" "items.append(42)" 20000 loops, best of 3: 0.506 usec per loop \$ python -m timeit -n20000 -s"items = [42]*10**6" "items.append(42)" 20000 loops, best of 3: 0.512 usec per loop \$ python -m timeit -n20000 -s"items = [42]*10**6" "items.append(42)" 20000 loops, best of 3: 0.543 usec per loop \$ python -m timeit -n20000 -s"items = [42]*10**6" "items.append(42)" 20000 loops, best of 3: 0.522 usec per loop \$ python -m timeit -n20000 -s"items = [42]*10**6" "items.append(42)" 20000 loops, best of 3: 0.51 usec per loop The difference is within the error margin. All you can say is that both operations take roughly the same time. In general, if no error margin (e. g. 0.5+-0.1) is given that is always a warning sign, be it opinion polls or timeit output. Peter Jun 30 '08 #5

 P: n/a Larry Bates wrote: [...] So its actually faster to append to a long list than an empty one? That certainly would not have been intuitively obvious now would it? Maybe not intuitively, but if you know how dynamically growing data structures are implemented, it's plausible. They overallocate, and the amount of overallocation is dependent on the current size. Relevant source snippet from Python 2.6: /* This over-allocates proportional to the list size, making room * for additional growth. The over-allocation is mild, but is * enough to give linear-time amortized behavior over a long * sequence of appends() in the presence of a poorly-performing * system realloc(). * The growth pattern is: 0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ... */ new_allocated = (newsize >3) + (newsize < 9 ? 3 : 6); If, on the other hand, we knew beforehand how big the list will get approximately, we could avoid all these reallocations. No problem with Python's C API: PyAPI_FUNC(PyObject *) PyList_New(Py_ssize_t size); But you can't do it directly from Python, unless you (ab)use ctypes. -- Gerhard Jun 30 '08 #6

 P: n/a Le Monday 30 June 2008 15:13:30 Larry Bates, vous avez écrit*: Peter Otten wrote: Ampedesign wrote: If I happen to have a list that contains over 50,000 items, will the size of the list severely impact the performance of appending to the list? No. \$ python -m timeit -n20000 -s"items = []" "items.append(42)" 20000 loops, best of 3: 0.554 usec per loop \$ python -m timeit -n20000 -s"items = [42]*10**6" "items.append(42)" 20000 loops, best of 3: 0.529 usec per loop http://wiki.python.org/moin/TimeComplexity Peter Peter, So its actually faster to append to a long list than an empty one? That certainly would not have been intuitively obvious now would it? That test only demonstrates that it's faster to append to a 1 million items list than an empty one (and this on a particular platform with a particular python version). Different sizes may give different result. I guess this is because of some internal optimisations (items are probably allocated by chunks, so sometimes append() involves a realloc, sometimes not). So the only thing you should remember is that list.append() has a complexity of O(1), and thus should be considered a constant time operation for any length. Just be aware of the note: [1] = These operations rely on the "Amortized" part of "Amortized Worst Case". Individual actions may take surprisingly long, depending on the history of the container. Also note that 50000 items is a lot for a human being, not for a modern computer. -- Cédric Lucantis Jun 30 '08 #7

 P: n/a Le Monday 30 June 2008 15:52:56 Gerhard Häring, vous avez écrit*: Larry Bates wrote: [...] So its actually faster to append to a long list than an empty one? That certainly would not have been intuitively obvious now would it? Maybe not intuitively, but if you know how dynamically growing data structures are implemented, it's plausible. They overallocate, and the amount of overallocation is dependent on the current size. Relevant source snippet from Python 2.6: /* This over-allocates proportional to the list size, making room * for additional growth. The over-allocation is mild, but is * enough to give linear-time amortized behavior over a long * sequence of appends() in the presence of a poorly-performing * system realloc(). * The growth pattern is: 0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ... */ new_allocated = (newsize >3) + (newsize < 9 ? 3 : 6); If, on the other hand, we knew beforehand how big the list will get approximately, we could avoid all these reallocations. No problem with Python's C API: PyAPI_FUNC(PyObject *) PyList_New(Py_ssize_t size); But you can't do it directly from Python, unless you (ab)use ctypes. -- Gerhard -- http://mail.python.org/mailman/listinfo/python-list Well, as I posted few days ago, one could envisage, as a pure python optimization for dealing with long list, to replace an algorithm with a lot of append by something like this : mark = object() datas = [ mark ] * expected_size # working with the datas while maintaining the effective currrently used size Of course one could even subclass list and redefine __len__, append, and some other methods to deal with this "allocated by block" list. -- _____________ Maric Michaud Jun 30 '08 #8

 P: n/a Maric Michaud wrote: Le Monday 30 June 2008 15:52:56 Gerhard Häring, vous avez écrit : >Larry Bates wrote: >If, on the other hand, we knew beforehand how big the list will getapproximately, we could avoid all these reallocations. No problem withPython's C API:PyAPI_FUNC(PyObject *) PyList_New(Py_ssize_t size);But you can't do it directly from Python, unless you (ab)use ctypes.-- Gerhard--http://mail.python.org/mailman/listinfo/python-list Well, as I posted few days ago, one could envisage, as a pure python optimization for dealing with long list, to replace an algorithm with a lot of append by something like this : mark = object() datas = [ mark ] * expected_size datas = [None] * expected_size has been a standard idiom since before object() existed ;-) and works fine *unless* one wants to add None explicitly and have that be different from 'unused'. > # working with the datas while maintaining the effective currrently used size Of course one could even subclass list and redefine __len__, append, and some other methods to deal with this "allocated by block" list. An interesting idea if one does this at least a few times and wants to use .append and .extend instead of explicit indexing. One could also make such a subclass a 'no-grow' list if appropriate (when an attempt to grow it would indicate a bug). tjr Jun 30 '08 #9

 P: n/a Le Monday 30 June 2008 22:21:35 Terry Reedy, vous avez écrit*: Well, as I posted few days ago, one could envisage, as a pure python optimization for dealing with long list, to replace an algorithm with a lot of append by something like this : mark = object() datas = [ mark ] * expected_size datas = [None] * expected_size has been a standard idiom since before object() existed ;-) and works fine *unless* one wants to add None explicitly and have that be different from 'unused'. Yes, in fact I used a marker because it I thought of it primarily as outbound for the list (like \0 for strings in C), but it doesnt' matter what is the object you put in the list, if you know at every moment its size. A subclass of list will indeed have to override most of the methods of its parent (not just some as I assumed before), using extend for reallocation with some sort of iterator with size, as it work in my previous example with xrange, something like that : >>>[31]: class iter_with_len(object) : def __init__(self, size, obj=None) : self.size = size self.obj = obj def __len__(self) : return self.size def __iter__(self) : return itertools.repeat(self.obj, len(self)) ....: ....: -- _____________ Maric Michaud Jun 30 '08 #10