Towards faster Python implementations - theory

[olsongt at verizon.net]

On May 9, 5:02 pm, John Nagle <n... at animats.com> wrote:
> Paul Boddie wrote:
>
>      Python has that capability mostly because it's free in an
> "everything is a dictionary" implementation.  ("When all you have
> is a hash, everything looks like a dictionary".)  But that limits
> implementation performance.  Most of the time, nobody is using
> "setattr" to mess with the internals of a function, class, or
> module from far, far away.  But the cost for that flexibility is
> being paid, unnecessarily.
>

I've had this idea in the back of my head for a year or so now, but
have been too lazy or busy or both to give the implementation a try.

The idea is to create a special dictionary for python internals that
contains a pointer-to-a-pointer for the value side of the dictionary,
instead of just the standard PyObject*.  Then when you start to eval a
code block, you could do a one-time lookup of the pointer-to-the-
pointer for each method, attribute, etc; and store them in pre-
allocated slots.  The calls in the block to various GET_ and SET_
functions can then just deal with pointer derefencing instead of a
dictionary lookup, and the dictionary can still get changed while this
is going on without things blowing up.

I think you'd get a big speed up by changing all those dictionary
function calls to inlined pointer deref code.

Anyone else buy this approach? Or see any fatal flaws?