[Python-Dev] PATCH: Fast globals/builtins lookups for 2.6

Neil Toronto ntoronto at cs.byu.edu
Thu Nov 29 22:07:40 CET 2007


Guido van Rossum wrote:
> Cool! Can't wait to get my hands on it. How does it affect pystone?

Pystone likes it, according to my tests and Chris's. On his machine, if 
I'm reading these stones right, it takes about 7% off the run time on 
average. On mine it takes off 4%.

> What happens if the globals are not a real dict but an instance of
> another collections.MutableMapping (virtual or real) subclass?

Globals has to be a real dict or a subclass, because otherwise 
PyFastGlobalsObject won't be able to point directly at its entries. This 
doesn't change anything, since globals had to be a real dict or subclass 
before.

> We've worked hard (well, some folks have) to enable this. It would be
> a show-stopper if this broke (or changed semantics or became
> significantly slower).

Besides what I outlined about __builtins__ (which should be an arbitrary 
implementation detail), everything is exactly the same. The details of 
fast globals are completely transparent to everything but PyDictObject 
(in which they're nearly insignificant) and PyFastGlobalsObject. In 
other words, every other bit of code in the interpreter can happily do 
whatever the heck it wants with globals and builtins without having to 
worry about messing anything up. Since it's nearly transparent to the 
interpreter core, Python-the-language shouldn't see any differences at all.

But then, I know less about the rest of the core than just about 
everybody else here, so I may just be talking out of my rear. :)

Pystone and my microbenchmarks look good, but we don't know yet about 
Pybench. On my tests, it's nearly the same, with small variations in 
individual tests. On Chris's, there are large variations that appear (to 
me) to be random. Pybench does almost nothing with globals, though - the 
numbers on that really only need to stay put.

Neil


More information about the Python-Dev mailing list