[Python-Dev] Speed up function calls

[Raymond Hettinger]

> > In theory, I don't see how you could improve on METH_O and METH_NOARGS.
> > The only saving is the time for the flag test (a predictable branch).
> > Offsetting that savings is the additional time for checking min/max args
> > and for constructing a C call with the appropriate number of args.  I
> > suspect there is no savings here and that the timings will get worse.
> 
> I think tested a method I changed from METH_O to METH_ARGS and could
> not measure a difference.  

Something is probably wrong with the measurements.  The new call does much more work than METH_O or METH_NOARGS.  Those two common and essential cases cannot be faster and are likely slower on at least some compilers and some machines.  If some timing shows differently, then it is likely a mirage (falling into an unsustainable local minimum).

The patch introduces range checks, an extra C function call, nine variable initializations, and two additional unpredictable branches (the case statements).  The only benefit (in terms of timing) is possibly saving a tuple allocation/deallocation.  That benefit only kicks in for METH_VARARGS and even then only when the tuple free list is empty.

I recommend not changing ANY of the METH_O and METH_NOARGS calls.  These are already close to optimal.



> A beneift would be to consolidate METH_O,
> METH_NOARGS, and METH_VARARGS into a single case.  This should
> make code simpler all around (IMO).

Will backwards compatibility allow those cases to be eliminated?  It would be a bummer if most existing extensions could not compile with Py2.5.  Also, METH_VARARGS will likely have to hang around unless a way can be found to handle more than nine arguments.

This patch appears to be taking on a life of its own and is being applied more broadly than is necessary or wise.  The patch is extensive and introduces a new C API that cannot be taken back later, so we ought to be careful with it.  

For the time being, try not to touch the existing METH_O and METH_NOARGS methods.  Focus on situations that do stand a chance of being improved (such as methods with a signature like "O|O").

That being said, I really like the concept.  I just worry that many of the stated benefits won't materialize:
* having to keep the old versions for backwards compatibility,
* being slower than METH_O and METH_NOARGS,
* not handling more than nine arguments,
* separating function signature info from the function itself,
* the time to initialize all the argument variables to NULL,
* somewhat unattractive case stmt code for building the c function call.



Raymond