From: Guido van Rossum <gu...@python.org> > > So here's how you can fix it: go to "Edit Issue" and change > the > "Base:" field to the following: > > http://svn.python.org/view/*checkout*/python/trunk/ >
I just deleted the issue altogether for now, since the preferred approach is to use a pointer, and that's gonna change the patch in lots of little places, so I think it would be wasteful to review it in its current form. > I'd like you to revisit this design decision. It would make > life > harder if we ever switched to a conservative garbage > collector. I feel > much more comfortable having a hard pointer to the actual > memory block > in my hands rather than having to compute where that block > starts > using pointer arithmetic. Ok, will do. > Note that I'm not endorsing your patch -- I expect that the > number of > (real) use cases that aren't already served better or > equally well by > deques is very small, and I fear that the real cost of > adding > sizeof(ssize_t) bytes to every list object is real (unless > there are 8 > bytes unused given the block size rounding happening in > obmalloc). I > don't believe a microbenchmark proves much of anything. > Fair enough. 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. 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. 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. _______________________________________________ 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
