[Python-Dev] Re: opcode performance measurements
Samuele Pedroni" <email@example.com
Fri, 1 Feb 2002 19:30:28 +0100
First, thanks for the answer :).
Here is my input on the topic
[Obviously I won't be present the developer day]
From: Jeremy Hylton <firstname.lastname@example.org>
> 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)
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 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