FDO: avoid Python function call overhead

[GoogleCodeExporter]

Building on the type/branch-recording code added in r778, we should 
make CALL_FUNCTION and co record which functions they're actually 
calling. I see two uses for this data:

a) In the case where we're calling PyCFunction objects, and the function is 
marked METH_NOARGS or METH_O, and the callsite argument signature 
matches the definition parameter signature exactly (probably limited to 
positional arguments), we can call the C function pointer directly, avoiding 
the complex argument/parameter matching at runtime and the creation of 
the argument tuple.

This scheme can be easily extended to all PyCFunctions with a constant 
number of positional arguments by encoding the number of arguments 
along with a new METH_* flag. A method for encoding this information has 
already been explored in the faster-c-calls branch.

b) In the case where we're calling pure-Python functions, we can do the 
argument/parameter checking and matching at compile time, rather than 
at runtime. We may still need to create the argument tuples/dicts in many 
cases, but we can figure out how to populate them at compile-time, rather 
than at runtime.

Support for methods may need to unpack the method wrapper objects to 
get at the underlying function objects and record that.

Original issue reported on code.google.com by collinw on 25 Jul 2009 at 9:38

[GoogleCodeExporter]

Original comment by collinw on 4 Aug 2009 at 1:15

• Changed state: Started

[GoogleCodeExporter]

The change to make direct calls to C functions was committed in r840. This will 
still 
benefit from more aggressive conditional constprop.

I've done some of the preliminary analysis on applying the same idea to 
pure-Python 
functions. I'm not sure how much savings there is there, given that we can't 
really avoid 
creating the PyFrameObject (barring something tremendously clever).

Original comment by collinw on 29 Sep 2009 at 12:34

• Added labels: Priority-Medium, Release-2009Q4
• Removed labels: Priority-High, Release-2009Q3

[GoogleCodeExporter]

Original comment by collinw on 6 Jan 2010 at 11:43

• Removed labels: Release-2009Q4