[Python-Dev] Re: opcode performance measurements (original) (raw)

Jeremy Hylton jeremy@alum.mit.edu
Fri, 1 Feb 2002 10:10:58 -0500

It just occurred to me that my LOADGLOBAL/LOADATTR eliding scheme can't work, since LOADATTR calls PyObjectGetAttr, which can wind up calling getattr, which is free to inflict all sorts of side effects on the attribute lookup. PEP 267 doesn't appear to be similarly affected, assuming it can conclude that LOADGLOBAL is actually loading a module object. (Can it?) LOADGLOBAL alone shouldn't be a problem, since all that does is call PyDictGetItem for globals and builtins.

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".

Jeremy