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

[Guido van Rossum]

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/)