[Python-Dev] Speed up function calls

[Neal Norwitz]

On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <python at rcn.com> wrote:
> > 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.

I was just trying to point out possible directions.  I wasn't trying
to suggest that the patch as a whole should be integrated now.

> > 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?

The compiler wouldn't know anything about pow().  It would only know
that 2 arguments are passed.  That would help get rid of the first
switch statement.
I need to think more about the NULL initialization.  I may have mixed
2 separate issues.

> > 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.

I really didn't want to do this now (or necessarily in 2.5).  I was
just trying to provide insight into future direction.  This brings up
another discussion about working towards 3.0.  But I'll make a new
thread for that.

At this point, it seems there aren't many disagreements about the
general idea.  There is primarily a question about what is acceptable
now.  I will rework the patch based on Raymond's feedback and continue
update the tracker.  Unless if anyone disagrees, I don't see a reason
to continue the remainder of this discussion on py-dev.

Neal