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