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.