On Nov 29, 2007 1:07 PM, Neil Toronto <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
