[Python-Dev] PATCH: Fast globals/builtins lookups for 2.6
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
> 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.
More information about the Python-Dev