On Tue, Jan 26, 2010 at 12:46 PM, Steve Howell <showel...@yahoo.com> wrote: > It seems to me that the goal of keeping lists super-compact from a memory > standpoint is contradicted by the code in list_resize that optimistically > preallocates extra memory on appends.
Ah, but that applies for *large* lists. Adding 8 bytes to each list object applies to *all* lists. I betcha that many programs use many tiny lists. If I had a program that was growing and shrinking a list at both ends, I'd consider a deque. If I had a program that was growing and shrinking a list at the front, I'd consider maintaining the data backwards. Extensive use of pop(0) (and insert(0, x) I suppose) is only defensible if you also need to access the data by index and negative indexes are not an option. Think about that. > I'm not arguing against the tradeoff there, as I think that optimization has > a way more compelling CPU gain for most applications than the optimizations > I'm proposing. What I'm really saying is that there is some precedent to > waste a little memory to make CPython lists run faster. My gut says that the > trend of the future is more CPU scarcity than memory scarcity, but that's > just a WAG. I'm no expert in this area, but considering the cost of cache misses, I'm not so sure about that. > Just more food for thought--doing the memory management within listobject.c > is really a workaround to the limitations of the underlying memory manager. > It seems conceptually possible to me to design a memory manager that allows > you to shrink and extend memory chunks on both sides, without any extra > memory overhead for bookkeeping. I'm sure the devils in the details, of > course. Maybe, but that's a project of a different magnitude altogether. For better or for worse, the assumption is widely made that blocks are represented by a pointer to the start plus a length. And considering zero to have special properties has pretty good mathematical backup of you ask me. :-) -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
