homepage

This is an optimization ported from PyPy. [1] It tries to prevent bound
methods from being created by using the stack as a cache. I couldn't
apply this to builtin methods because those use a method-wrapper
descriptor. The results were not very impressive. However, I'm attaching
the patch to see if anyone else wants to look at it.
[1]
http://codespeak.net/pypy/dist/pypy/doc/interpreter-optimizations.html#id1
Test minimum run-time average run-time
 this other diff this other 
 diff
-------------------------------------------------------------------------------
 BuiltinFunctionCalls: 342ms 340ms +0.6% 378ms 361ms
 +4.7%
 BuiltinMethodLookup: 315ms 308ms +2.3% 333ms 319ms
 +4.5%
 CompareFloats: 250ms 251ms -0.3% 257ms 258ms
 -0.7%
 CompareFloatsIntegers: 266ms 265ms +0.4% 273ms 273ms
 -0.2%
 CompareIntegers: 233ms 232ms +0.4% 238ms 238ms
 -0.2%
 CompareInternedStrings: 279ms 275ms +1.3% 285ms 284ms
 +0.3%
 CompareLongs: 225ms 223ms +1.1% 231ms 229ms
 +0.8%
 CompareStrings: 238ms 235ms +1.3% 244ms 243ms
 +0.6%
 CompareUnicode: 243ms 246ms -0.9% 252ms 252ms
 -0.1%
 ComplexPythonFunctionCalls: 307ms 301ms +2.0% 315ms 309ms
 +1.8%
 ConcatStrings: 372ms 366ms +1.6% 376ms 385ms
 -2.1%
 ConcatUnicode: 260ms 259ms +0.4% 266ms 269ms
 -0.9%
 CreateInstances: 351ms 336ms +4.7% 365ms 346ms
 +5.5%
 CreateNewInstances: 265ms 256ms +3.6% 281ms 264ms
 +6.5%
 CreateStringsWithConcat: 290ms 289ms +0.1% 304ms 301ms
 +1.2%
 CreateUnicodeWithConcat: 220ms 219ms +0.8% 227ms 223ms
 +1.8%
 DictCreation: 201ms 200ms +0.4% 204ms 206ms
 -1.0%
 DictWithFloatKeys: 400ms 418ms -4.4% 410ms 424ms
 -3.4%
 DictWithIntegerKeys: 298ms 294ms +1.2% 306ms 304ms
 +0.6%
 DictWithStringKeys: 260ms 264ms -1.5% 270ms 275ms
 -2.1%
 ForLoops: 224ms 223ms +0.2% 232ms 232ms
 +0.2%
 IfThenElse: 160ms 160ms +0.0% 168ms 182ms
 -8.0%
 ListSlicing: 293ms 292ms +0.5% 302ms 306ms
 -1.2%
 NestedForLoops: 301ms 300ms +0.2% 305ms 308ms
 -0.8%
 NestedListComprehensions: 323ms 328ms -1.7% 331ms 335ms
 -1.3%
 NormalClassAttribute: 313ms 314ms -0.1% 323ms 330ms
 -2.1%
 NormalInstanceAttribute: 284ms 283ms +0.4% 289ms 288ms
 +0.4%
 PythonFunctionCalls: 259ms 278ms -6.7% 274ms 289ms
 -5.3%
 PythonMethodCalls: 358ms 357ms +0.3% 371ms 365ms
 +1.6%
 Recursion: 389ms 398ms -2.1% 395ms 407ms
 -2.9%
 SecondImport: 335ms 319ms +5.2% 346ms 380ms
 -8.9%
 SecondPackageImport: 338ms 326ms +3.6% 350ms 337ms
 +4.0%
 SecondSubmoduleImport: 413ms 403ms +2.5% 426ms 411ms
 +3.6%
 SimpleComplexArithmetic: 341ms 345ms -1.2% 351ms 355ms
 -1.1%
 SimpleDictManipulation: 288ms 298ms -3.7% 293ms 303ms
 -3.1%
 SimpleFloatArithmetic: 272ms 275ms -1.1% 279ms 286ms
 -2.7%
 SimpleIntFloatArithmetic: 211ms 204ms +3.3% 216ms 215ms
 +0.5%
 SimpleIntegerArithmetic: 207ms 203ms +1.7% 214ms 213ms
 +0.5%
 SimpleListComprehensions: 275ms 273ms +0.6% 281ms 281ms
 -0.1%
 SimpleListManipulation: 224ms 229ms -2.5% 234ms 241ms
 -2.9%
 SimpleLongArithmetic: 252ms 253ms -0.6% 263ms 266ms
 -1.0%
 SmallLists: 290ms 301ms -3.8% 299ms 311ms
 -3.9%
 SmallTuples: 254ms 253ms +0.3% 261ms 266ms
 -1.9%
 SpecialClassAttribute: 311ms 309ms +0.7% 320ms 321ms
 -0.2%
 SpecialInstanceAttribute: 358ms 358ms +0.1% 370ms 371ms
 -0.4%
 StringMappings: 817ms 833ms -1.9% 823ms 852ms
 -3.4%
 StringPredicates: 488ms 538ms -9.2% 495ms 547ms
 -9.4%
 StringSlicing: 295ms 296ms -0.2% 306ms 323ms
 -5.5%
 TryExcept: 282ms 280ms +1.0% 291ms 288ms
 +1.0%
 TryFinally: 290ms 255ms +14.1% 300ms 263ms
 +14.1%
 TryRaiseExcept: 261ms 256ms +1.7% 271ms 263ms
 +3.1%
 TupleSlicing: 281ms 270ms +4.3% 289ms 277ms
 +4.3%
 UnicodeMappings: 329ms 337ms -2.4% 337ms 348ms
 -3.0%
 UnicodePredicates: 295ms 329ms -10.4% 303ms 338ms
 -10.5%
 UnicodeProperties: 272ms 307ms -11.4% 284ms 313ms
 -9.3%
 UnicodeSlicing: 258ms 261ms -1.2% 266ms 275ms
 -3.2%
 WithFinally: 384ms 398ms -3.6% 394ms 408ms
 -3.5%
 WithRaiseExcept: 320ms 294ms +8.9% 336ms 304ms
 +10.6%
-------------------------------------------------------------------------------

Can you give results of the "richards" benchmark?

With the patch:
Richards benchmark (Python) starting... [<function entry_point at 0x63b430>]
finished.
Total time for 10 iterations: 8.49 secs
Average time per iteration: 848.90 ms
Without:
Richards benchmark (Python) starting... [<function entry_point at 0x637530>]
finished.
Total time for 10 iterations: 10.46 secs
Average time per iteration: 1045.88 ms

Similar results here.
With the patch:
Richards benchmark (Python) starting... [<function entry_point at
0x7fc15b3f5848>]
finished.
Total time for 4 iterations: 1.78 secs
Average time per iteration: 443.90 ms
Without the patch:
Richards benchmark (Python) starting... [<function entry_point at
0x7f8b9fb20848>]
finished.
Total time for 4 iterations: 2.02 secs
Average time per iteration: 503.79 ms

One thing I was wondering about the current patch is what about objects
that have attributes that shadow methods? For example:
class C(object):
 def foo(self):
 return 1
c = c()
print c.foo()
c.foo = lambda: 2
print c.foo()
Shouldn't the above print 1 and 2? With the current patch, it seems
that you might still print 1.
There's also the possible performance drawback where you're loading
builtin C methods, so the optimization fails, but you end up calling
_PyType_Lookup twice. :(
I'm doing the same optimization for unladen swallow, and these were some
of the things I ran into. I think I'm going to write a
PyObject_GetMethod that tries to get a method without binding it, but if
it can't for any reason, it behaves just like PyObject_GetAttr and sets
a status code.

Yes, my patch introduces that regression you mention. PyPy solves this
by having the instances dictionary keep track of shadowing of the type
dictionary. Not easy for CPython... I wish you luck on your patch!

I have an patch for unladen-swallow out for review here:
http://codereview.appspot.com/160063/show
It resolves the correctness issues I mentioned previously by emitting guards if necessary. If the type is predictable and uses slots, then we don't need to check the instance dict.
It gives a 5% speedup on the unpickle benchmark. Presumably the other benchmarks do not do as many method calls.

First, are these benchmark results jitted or non-jitted? Right now, non-jitted results are a stronger motivation for inclusion in main CPython, IMHO. 
Second, 2.7 won't receive any features / performance improvements anymore. It would be nice to have 3.2 (non-jitted) benchmark results.
Third, if removing intermediate allocations is the kind of optimizations a JIT will do anyway, does it make sense or not to make these optimizations explicit at the bytecode level? (this is really an open question, not a rhetorical one)

Sorry, I was just posting it so Benjamin could see what this bought us. I'm not pushing to get this in CPython.
The results are for JITed code. I forget what the interpreted results are. I think they are good for the microbenchmarks, but not as good for the macro.

Benjamin confirms a regression in his patch, and the other patch was not intended for CPython. So I'm closing this issue.