> Where are the attempts to speed up function/method calls? That's an
> area where we could *really* use a breakthrough...
At one time you had entertained treating some of the builtin calls as
fixed. Is that something you want to go forward with? It would entail
a "from __future__" and transition period.
It would not be hard to take code like "return len(alist)" and transform
it from:
2 0 LOAD_GLOBAL 0 (len)
3 LOAD_FAST 0 (alist)
6 CALL_FUNCTION 1
9 RETURN_VALUE
to:
2 0 LOAD_FAST 0 (alist)
3 OBJECT_LEN
4 RETURN_VALUE
Some functions already have a custom opcode that cannot be used unless
we freeze the meaning of the function name:
repr --> UNARY_CONVERT --> PyObject_Repr
iter --> GET_ITER --> PyObject_GetIter
Alternately, functions could be served by a table of known, fixed
functions:
2 0 LOAD_FAST 0 (alist)
3 CALL_DEDICATED 0 (PyObject_Len)
6 RETURN_VALUE
where the dispatch table is something like: [PyObject_Len,
PyObject_Repr, PyObject_IsInstance, PyObject_IsTrue, PyObject_GetIter,
...].
Of course, none of these offer a big boost and there is some loss of
dynamic behavior.
Raymond
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