[Python-Dev] Speed up function calls (original) (raw)

Neal Norwitz nnorwitz at gmail.com
Sun Jan 30 21:40:35 CET 2005

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

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

So, leave METHO and METHNOARGS 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. CALLFUNCTION0, > CALLFUNCTION1, ... > (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 evalframe 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 METHO and METHNOARGS. 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

More information about the Python-Dev mailing list