Towards faster Python implementations - theory

John Nagle nagle at animats.com
Tue May 8 11:53:33 EDT 2007


    Some faster Python implementations are under development.
JPython has been around for a while,  and PyPy and ShedSkin
continue to move forward.  It's worth thinking about what slows
down Python implementations.

    It isn't the dynamism, really.  As others have pointed out
in the Python literature, most of the time, the more elaborate
dynamic features aren't being used for any given variable or
object.  If code has something like "x = 1.0", the odds are that
"x" is going to stay a floating point number, and not suddenly turn
into a list or an object reference.  The type inference of Shed Skin
builds on that assumption, adding some restrictions about changing of
variable types.

    The Shed Skin effort indicates that explicit typing, via 'decorators'
or otherwise, isn't really necessary.  What's necessary is the avoidance
of "surprises" in the language.  In this context, a "surprise" is
the use of a dynamic feature in a way that can't be seen at compile time.

    A typical "surprise" would be the use of "setattr" on an object from
outside the compilation unit that defines the object.  Within a module,
"setattr" on an object in that module is no problem; the compiler can see
it and generate the extra machinery needed to make an object dynamically
alterable at run time.  But if an object doesn't need that extra machinery
and associated dictionary, it's a big win to discard the excess baggage
and use a simpler fixed-size representation, comparable to a C struct,
for the object.

    On the typing front, the neatest way to express typing is via
initialization.  With the Shed Skin restrictions, if all variables are
initialized before use (preferably in __init__), there's no need to
maintain an "undefined" flag for a variable.  And, of course, if
the type of a varaible is simple and can't change, it doesn't have to
be "boxed", (enclosed in an object) which is a big win.

    The point here is that we don't need language changes or declarations
to make Python much faster.  All we need are a few restrictions that
insure that, when you're doing something unusual, the compiler can
tell.

    				John Nagle



More information about the Python-list mailing list