Raymond Hettinger <raymond.hettinger <at> gmail.com> writes: > > AFAICT, the performance of the proposal: > > * increases space requirements by a small fixed amount
Well, given my proposal (assuming it turns out ok) it doesn't. > * s.append() performance slightly degraded. Why? > * the resize performance doesn't work well with the > memory allocator -- while a series of appends can often > resize in-place without a need to do an O(n) memmove, > but a series of pop(0) calls doesn't have a resize in-place > option. "Can often resize in-place" is overstated. It only works if there's a chunk of sufficient free space just after your list's storage, which is probably not the common case (except perhaps in microbenchmarks where the list is the latest allocated object). > What currently unknown is the effect on third-party extensions > and debugging tools that access the structure directly. > Also, am not sure if this affects psyco or the other > implementations such as Jython which may implement > lists in terms of existing Java containers. Well, if psyco wants to muck with internal implementation details, it's psyco's problem. We shouldn't refrain from making internal changes under the pretext that it might break psyco. Otherwise the psyco author(s) should file a PEP for inclusion in the core interpreter ;) Regards Antoine. _______________________________________________ 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
