[Python-ideas] Save memory when forking with *really* immutable objects

Nick Coghlan ncoghlan at gmail.com
Fri Mar 23 02:16:49 CET 2012

On Fri, Mar 23, 2012 at 10:40 AM, Barry Warsaw <barry at python.org> wrote:
> It's been *ages* since I really knew how any of this worked, but I think some
> flavor of the Objective-C runtime did reference counting this way.  I think
> this afforded them other tricks, like the ability to not increment the
> refcount for an object if it was exactly 1.  I've no doubt someone here will
> fill in all my faulty memory and gaps, but I do seem to recall it being a
> pretty efficient system for memory management.

Also from the world of "hazy memories of old discussions", my
recollection is that the two main problems with the indirection are:

- an extra pointer indirection for every refcounting operation (which
are frequent enough that the micro-pessimisation has a measurable
- some loss of cache locality (since every Python object will need
both its own memory and its refcount memory in the cache)

Larry's suggestion for allowing eternal objects avoids the latter
problem, but still suffers from (a variant of) the first. As the many
GIL discussions can attest, we're generally very reluctant to accept a
single-threaded (or, in this case, single process) performance hit to
improve behaviour in the concurrent case.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-ideas mailing list