At 04:49 PM 2/27/04 -0500, Fred L. Drake, Jr. wrote: >On Friday 27 February 2004 03:20 am, Raymond Hettinger wrote: > > I've been working on ways to speedup parameter passing for function > > calls. It's somewhat expensive to pull parameters off of the stack, > > assemble them into a new tuple, have the function disassemble the tuple, > > and ultimately free the tuple. >.. > > My idea is for a new flag, METH_STACK, that generalizes (and potentially > > replaces) METH_NOARGS AND METH_O. > >How would METH_STACK methods work when called via func(*args) or via the >various functions of the C API? > >The nice thing about METH_NOARGS and METH_O is that they describe what the >called function needs. METH_STACK sounds like a core dump waiting to >happen. >;-( Maybe there should instead be a tp_call_stack slot. Then the various CALL opcodes would call that slot instead of tp_call. C API calls would still go through tp_call. 'object' would define tp_call_stack to call tp_call, using information from the stack. Python function and method objects would then override tp_call_stack to implement the shortcut form. In practice, though, I expect it would be faster to do as Jython and IronPython have done, and define a set of tp_call1, tp_call2, etc. slots that are optimized for specific calling situations, allowing C API calls to be sped up as well, provided you used things like PyObject_Call1(ob,arg), PyObject_Call2(ob,arg1,arg2), and so on. Perhaps there is some information that can be gleaned from the Jython research as to what are the most common number of positional parameters for calls.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4