[Python-Dev] Re: opcode performance measurements

Jeremy Hylton jeremy@alum.mit.edu
Fri, 1 Feb 2002 20:15:21 -0500

>>>>> "SP" == Samuele Pedroni <pedronis@bluewin.ch> writes:

  SP> * instance namespaces

  SP> As I said but what eventually will happen with class/type
  SP> unification plays a role.

  SP> 1. __slots__ are obviously a good thing here :)
  SP> 2. old-style instances and in general instances with a dict:

  SP> one can try to guess the slots of a class looking for the
  SP> "self.attr" pattern at compile time in a more or less clever
  SP> way.  The set of compile-time guessed attrs will be passed to
  SP> MAKE_CLASS which will construct the runtime guess using the
  SP> union of the super-classes guesses and the compile time guess
  SP> for the class.  This information can be used to layout a dlict.

Right!  There's another step necessary to take advantage though.  When
you execute a method you don't know the receiver type
(self.__class__).  So you need to specialize the bytecode to a
particular receiver the first time the method is called.  Since this
could be relatively expensive and you don't know how often the method
will be executed, you need to decide dynamically when to do it.  Just
like HotSpot.

We probably have to worry about a class or instance being modified in
a way that invalidates the dlict offsets computed.  (Not sure here,
but I think that's the case.)  If so, we probably need a different
object -- call it a template -- that represents the concrete layout
and is tied to unmodified concrete class.  When objects or classes are
modified in dangerous ways, we'd need to invalidate the template
pointer for the affected instances.