[Python-Dev] Re: opcode performance measurements

[Samuele Pedroni]

First, thanks for the answer :).
Here is my input on the topic 
[Obviously I won't be present the developer day]

From: Jeremy Hylton <jeremy@alum.mit.edu>
> The approach I'm working on would have to check that the object is a module
> on each use, but that's relatively cheap compared to the layers of function
> calls we have now.  It's a pretty safe assumption because it would only be
> made for objects bound by an import statement.
> 
> I also wanted to answer Samuele's question briefly, because I'm going to be
> busy with other things most of today.  The basic idea, which I need to flesh
> out by next week, is that the internal binding for "mod.attr" that a module
> keeps is just a hint.  The compiler notices that function f() uses
> "mod.attr" and that mod is imported at the module level.  The "mod.attr"
> binding must include a pointer to the location where mod is stored and the
> pointer it found when the "mod.attr" binding was updated.  When "mod.attr"
> is used, the interpreter must check that mod is still bound to the same
> object.  If so, the "mod.attr" binding is still valid.  Note that the
> "mod.attr" binding is a PyObject ** -- a pointer to the location where
> "attr" is bound in "mod".
> 

I see, btw I asked primarily because the PEP as it is is vague, not
because I believed the idea cannot fly [for Jython the issue
is more complicated, PyObject ** is not something easily
expressed in Java <wink>]

I think that it is worth to point out that what you propose is a special/
ad-hoc version of what typically other Smalltalk-like dynamic languages do,
together with jitting, but the approach is orthogonal to that, namely:

for every send site they have a send-site cache:

   if send-site-cache-still-applies: # (1)
     dispatch based on site-cache contents # (2)
  else:
    normal send lookup and update send-site-cache

In Python more or less the same could be applied
to load_* instead of sends.

Your approach deals with a part of those. These need
(only) module-level caches.

The extended/general approach could work too and
give some benefit.

But it is clear that the complexity and overhead of (1) and (2),
and the space-demand for the caches depend 
on how much homogeneous are system object layouts 
and behaviors.

And Python with modules, data-objects, class/instances,
types etc is quite a zoo :(.

Pushing the class/type unification further, this is an aspect
to consider IMHO.

If those things where already all known sorry for the
boring post.

regards.