[Python-Dev] Speed up function calls

[Raymond Hettinger]

> I agree that METH_O and METH_NOARGS are near
> optimal wrt to performance.  But if we could have one METH_UNPACKED
> instead of 3 METH_*, I think that would be a win.
 . . .
> Sorry, I meant eliminated w/3.0. 

So, leave METH_O and METH_NOARGS alone.  They can't be dropped until 3.0
and they can't be improved speedwise.



> > * not handling more than nine arguments,
> 
> There are very few functions I've found that take more than 2
arguments.

It's not a matter of how few; it's a matter of imposing a new, arbitrary
limit where none previously existed.  This is not a positive point for
the patch.



> Ultimately, I think we can speed things up more by having 9 different
> op codes, ie, one for each # of arguments.  CALL_FUNCTION_0,
> CALL_FUNCTION_1, ...
> (9 is still arbitrary and subject to change)

How is the compiler to know the arity of the target function?  If I call
pow(3,5), how would the compiler know that pow() can take an optional
third argument which would be need to be initialized to NULL?



> Then we would have N little functions, each with the exact # of
> parameters.  Each would still need a switch to call the C function
> because there may be optional parameters.  Ultimately, it's possible
> the code would be small enough to stick it into the eval_frame loop.
> Each of these steps would need to be tested, but that's a possible
> longer term direction.
 . . .
> There would only be an if to check if it was a C function or not.
> Maybe we could even get rid of this by more fixup at import time.

This is what I mean about the patch taking on a life of its own.  It's
an optimization patch that slows down METH_O and METH_NOARGS.  It's a
incremental change that throws away backwards compatibility.  It's a
simplification that introduces a bazillion new code paths.  It's a
simplification that can't be realized until 3.0.  It's a minor change
that entails new opcodes, compiler changes, and changes in all
extensions that have ever been written.

IOW, this patch has lost its focus (or innocence).  That can be
recovered by limiting the scope to improving the call time for methods
with signatures like "O}O".  That is an achievable goal that doesn't
impact backwards compatibility, doesn't negatively impact existing
near-optimal METH_O and METH_NOARGS code, doesn't mess with the
compiler, doesn't introduce new opcodes, doesn't alter import logic, and
doesn't muck-up existing extensions.



Raymond


"Until next week, keep your feet on the ground and keep reaching for the
stars." -- Casey Kasem