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

Reply via email to