[Python-Dev] stackable ints [stupid idea (ignore) :v]

Aaron Watters arw at ifu.net
Thu Jun 10 15:40:51 CEST 1999

While we're talking about stacks...

I've always considered it a major shame that Python ints and floats
and chars and stuff have anything to do with dynamic allocation, and I
always suspected it might be a major speed performance boost if there
some way they could be manipulated without the need for dynamic
memory management.

One conceivable alternative approach would change the basic manipulation
objects so that instead of representing objects via pyobject pointers
represent them using two "slots" in a structure for each object,
one of which is a type descriptor pointer and the other
being a (void *) which could contain the data directly for small objects

such as ints, floats, chars.  In this case, for example, integer
addition would
never require any memory management, as it shouldn't, I think, in a

IE instead of

      C-stack or static:                      Heap:
     (pyobject *)     ------------>   (refcount, typedescr, data ...)

in general you get

      repr* ----------------------> (refcount, data, ...)

or for small objects like ints and floats and chars simply


with no dereferencing or memory management required.  My feeling is
that common things like arithmetic and indexing lists of integers and
stuff could
be much faster under this approach since it reduces memory management
overhead and fragmentation, dereferencing, etc...

One bad thing, of course, is that this might be a drastic assault on the

way existing code works...  Unless I'm just not being creative enough
with my thinking.  Is this a good idea?  If so, is there any way to add
to the interpreter without breaking extension modules and everything
If Python 2.0 will break stuff anyway, would this be an good change
to the internals?

Curious...   -- Aaron Watters

ps: I suppose another gotcha is "when do you do increfs/decrefs?"
  they no longer make sense for ints in this case...  maybe add a flag
to the
  type descriptor "increfable" and assume that the typedescriptors are
  in the CPU cache (?). This would slow down increfs by a couple
  Would it be worth it?  Only the benchmark knows...  Another fix would
  to put the refcount in the static side with no speed penalty

      repr* ----------------------> data

  but would that be wasteful of space?

More information about the Python-Dev mailing list