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

Guido van Rossum guido at python.org
Thu Nov 29 23:05:47 CET 2007

On Nov 29, 2007 1:07 PM, Neil Toronto <ntoronto at cs.byu.edu> wrote:

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

Hm.

On my Linux box, in the trunk:

Before the patch: Pystone(1.1) time for 50000 passes = 1.16 This machine benchmarks at 43103.4 pystones/second

After the patch: Pystone(1.1) time for 50000 passes = 1.14 This machine benchmarks at 43859.6 pystones/second

That's only about 1.75% faster. But pystone is a lousy benchmark.

> 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. :)

My apologies. I though I remembered we changed exec() and eval() to accept a totally arbitrary mapping for globals() -- but that's not the case, it must be a dict subclass.

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.

The only pybench tests that matter would be the ones checking dict performance.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list