"Raymond Hettinger" <raymond.hettinger at verizon.net> writes: > 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. Yahbut... that doesn't actually happen all that often. > METH_NOARGS and METH_O show nice speed-ups by skipping the tuple packing > and unpacking. Since they are handled as special cases, that approach > doesn't handle the general case with multiple or optional arguments. Oh, you're talking about builtin functions. > My idea is for a new flag, METH_STACK, that generalizes (and potentially > replaces) METH_NOARGS AND METH_O. > > When CALL_FUNCTION sees the flag, it dispatches (*meth)(self, &stack, > numargs). > > On the receiving end, the arguments get retrieved with analogues to > PyArg_ParseTuple() and PyArg_UnpackTuple() which access the parameters > directly and do not need a tuple as a carrier. Have you seen my "function optimization reorganization" patch on SF? It's a somewhat different result of somewhat similar thinking. http://python.org/sf/876193 Cheers, mwh -- Java sucks. [...] Java on TV set top boxes will suck so hard it might well inhale people from off their sofa until their heads get wedged in the card slots. --- Jon Rabone, ucam.chat
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