iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 266, Optimizing Global Variable/Attribute Access, Skip Montanaro 

Minor editorial pass, spell checking, formatting.  I also had to
shorten the title, hope Skip doesn't mind!
This commit is contained in:
Barry Warsaw 2001-08-15 00:05:34 +00:00
parent 7a54f094ef
commit f51ea84522
1 changed files with 204 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

204
pep-0266.txt Normal file
View File

@ -0,0 +1,204 @@
PEP: 266
Title: Optimizing Global Variable/Attribute Access
Version: $Revision$
Author: skip@pobox.com (Skip Montanaro)
Status: Draft
Type: Standards Track
Python-Version: 2.3
Created: 13-Aug-2001
Post-History:
Abstract
The bindings for most global variables and attributes of other
modules typically never change during the execution of a Python
program, but because of Python's dynamic nature, code which
accesses such global objects must run through a full lookup each
time the object is needed. This PEP proposes a mechanism that
allows code that accesses most global objects to treat them as
local objects and places the burden of updating references on the
code that changes the name bindings of such objects.
Introduction
Consider the workhorse function sre_compile._compile. It is the
internal compilation function for the sre module. It consists
almost entirely of a loop over the elements of the pattern being
compiled, comparing opcodes with known constant values and
appending tokens to an output list. Most of the comparisons are
with constants imported from the sre_constants module. This means
there are lots of LOAD_GLOBAL bytecodes in the compiled output of
this module. Just by reading the code it's apparent that the
author intended LITERAL, NOT_LITERAL, OPCODES and many other
symbols to be constants. Still, each time they are involved in an
expression, they must be looked up anew.
Most global accesses are actually to objects that are "almost
constants". This includes global variables in the current module
as well as the attributes of other imported modules. Since they
rarely change, it seems reasonable to place the burden of updating
references to such objects on the code that changes the name
bindings. If sre_constants.LITERAL is changed to refer to another
object, perhaps it would be worthwhile for the code that modifies
the sre_constants module dict to correct any active references to
that object. By doing so, in many cases global variables and the
attributes of many objects could be cached as local variables. If
the bindings between the names given to the objects and the
objects themselves changes rarely, the cost of keeping track of
such objects should be low and the potential payoff fairly large.
Proposed Change
I propose that the Python virtual machine be modified to include
TRACK_OBJECT and UNTRACK_OBJECT opcodes. TRACK_OBJECT would
associate a global name or attribute of a global name with a slot
in the local variable array and perform an initial lookup of the
associated object to fill in the slot with a valid value. The
association it creates would be noted by the code responsible for
changing the name-to-object binding to cause the associated local
variable to be updated. The UNTRACK_OBJECT opcode would delete
any association between the name and the local variable slot.
Rationale
Global variables and attributes rarely change. For example, once
a function imports the math module, the binding between the name
"math" and the module it refers to aren't likely to change.
Similarly, if the function that uses the math module refers to its
"sin" attribute, it's unlikely to change. Still, every time the
module wants to call the math.sin function, it must first execute
a pair of instructions:
LOAD_GLOBAL math
LOAD_ATTR sin
If the client module always assumed that math.sin was a local
constant and it was the responsibility of "external forces"
outside the function to keep the reference correct, we might have
code like this:
TRACK_OBJECT math.sin
...
LOAD_FAST math.sin
...
UNTRACK_OBJECT math.sin
If the LOAD_FAST was in a loop the payoff in reduced global loads
and attribute lookups could be significant.
This technique could, in theory, be applied to any global variable
access or attribute lookup. Consider this code:
l = []
for i in range(10):
l.append(math.sin(i))
return l
Even though l is a local variable, you still pay the cost of
loading l.append ten times in the loop. The compiler (or an
optimizer) could recognize that both math.sin and l.append are
being called in the loop and decide to generate the tracked local
code, avoiding it for the builtin range() function because it's
only called once during loop setup.
According to a post to python-dev by Marc-Andre Lemburg [1],
LOAD_GLOBAL opcodes account for over 7% of all instructions
executed by the Python virtual machine. This can be a very
expensive instruction, at least relative to a LOAD_FAST
instruction, which is a simple array index and requires no extra
function calls by the virtual machine. I believe many LOAD_GLOBAL
instructions and LOAD_GLOBAL/ LOAD_ATTR pairs could be converted
to LOAD_FAST instructions.
Code that uses global variables heavily often resorts to various
tricks to avoid global variable and attribute lookup. The
aforementioned sre_compile._compile function caches the append
method of the growing output list. Many people commonly abuse
functions' default argument feature to cache global variable
lookups. Both of these schemes are hackish and rarely address all
the available opportunities for optimization. (For example,
sre_compile._compile does not cache the two globals that it uses
most frequently: the builtin len function and the global OPCODES
array that it imports from sre_constants.py.
Discussion
Jeremy Hylton has an alternate proposal on the table [2]. His
proposal seeks to create a hybrid dictionary/list object for use
in global name lookups that would make global variable access look
more like local variable access. While there is no C code
available to examine, the Python implementation given in his
proposal still appears to require dictionary key lookup. It
doesn't appear that his proposal could speed local variable
attribute lookup, which might be worthwhile in some situations.
Backwards Compatibility
I don't believe there will be any serious issues of backward
compatibility. Obviously, Python bytecode that contains
TRACK_OBJECT opcodes could not be executed by earlier versions of
the interpreter, but breakage at the bytecode level is often
assumed between versions.
Implementation
TBD. This is where I need help. I believe there should be either
a central name/location registry or the code that modifies object
attributes should be modified, but I'm not sure the best way to go
about this. If you look at the code that implements the
STORE_GLOBAL and STORE_ATTR opcodes, it seems likely that some
changes will be required to PyDict_SetItem and PyObject_SetAttr or
their String variants. Ideally, there'd be a fairly central place
to localize these changes. If you begin considering tracking
attributes of local variables you get into issues of modifying
STORE_FAST as well, which could be a problem, since the name
bindings for local variables are changed much more frequently. (I
think an optimizer could avoid inserting the tracking code for the
attributes for any local variables where the variable's name
binding changes.)
Performance
I believe (though I have no code to prove it at this point), that
implementing TRACK_OBJECT will generally not be much more
expensive than a single LOAD_GLOBAL instruction or a
LOAD_GLOBAL/LOAD_ATTR pair. An optimizer should be able to avoid
converting LOAD_GLOBAL and LOAD_GLOBAL/LOAD_ATTR to the new scheme
unless the object access occurred within a loop. Further down the
line, a register-oriented replacement for the current Python
virtual machine [3] could conceivably eliminate most of the
LOAD_FAST instructions as well.
The number of tracked objects should be relatively small. All
active frames of all active threads could conceivably be tracking
objects, but this seems small compared to the number of functions
defined in a given application.
References
[1] http://mail.python.org/pipermail/python-dev/2000-July/007609.html
[2] http://www.zope.org/Members/jeremy/CurrentAndFutureProjects/FastGlobalsPEP
[3] http://www.musi-cal.com/~skip/python/rattlesnake20010813.tar.gz
Copyright
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: