Josiah Carlson writes: > On Thu, Jan 28, 2010 at 8:57 PM, Steve Howell <showel...@yahoo.com> wrote:
> > What do you think of LISP, and "car" in particular (apart from > > the stupidly cryptic name)? > Apples and oranges. True, but speaking of Lisp lists, here's some possibly relevant experience. About 10 years ago, XEmacs converted its cons type from a special immediate representation (ie, cons == (car, cdr)) to a generic record representation (ie, cons == (pointer to type descriptor, car, cdr)). This resulted in a perceptible increase in VM usage and disk usage. A typical running XEmacs instance for me contains about 0.75 million conses and uses 200MB of VM, so with 32-bit pointers that's about 3MB extra, or 1.5%, and with 64-bit pointers it's 6MB extra, about 3%. However, I tend to have several big buffers (20-50MB) of pure character data; people who work with smaller buffers on 64-bit machines have reported as much as 10% extra overhead. On disk, the binary is typically about 9MB stripped. That contains about 50,000 conses, or an extra 200KB/400KB with the new structure, somewhat more than my experience (2% or 4%). Some people complained, but we considered this well worthwhile (moving one "type bit" from the car to the header allowed Lisp integers to cover the range -1G to +1G, and there are a surprising number of people who would like to use XEmacs on files >512MB). I suppose that Steve's proposal probably has similar impact on binaries and running instances of Python, but he hasn't given any use cases for list.pop(0) to compared to doubling the size of usable buffers. _______________________________________________ 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