[Python-Dev] PATCH: Fast globals/builtins lookups for 2.6 (original) (raw)

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