On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com