Add Ping's "always doubly-indirect" idea. Remove mistaken pseudo-C
for Tim's ideal.
This commit is contained in:
parent
6a826bf8aa
commit
d4757ee5a2
21
pep-0280.txt
21
pep-0280.txt
|
@ -437,18 +437,23 @@ FAQs
|
|||
Py_INCREF(x);
|
||||
continue;
|
||||
|
||||
With Tim's "more aggressive" alternative added, it could look
|
||||
like this:
|
||||
We could even write it like this (idea courtesy of Ka-Ping Yee):
|
||||
|
||||
case LOAD_GLOBAL_CELL:
|
||||
cell = func_cells[oparg];
|
||||
x = cell->objptr;
|
||||
if (x == NULL) {
|
||||
... error recovery ...
|
||||
break;
|
||||
x = cell->cellptr->objptr;
|
||||
if (x != NULL) {
|
||||
Py_INCREF(x);
|
||||
continue;
|
||||
}
|
||||
Py_INCREF(x);
|
||||
continue;
|
||||
... error recovery ...
|
||||
break;
|
||||
|
||||
In modern CPU architectures, this reduces the number of
|
||||
branches taken for built-ins, which might be a really good
|
||||
thing, while any decent memory cache should realize that
|
||||
cell->cellptr is the same as cell for regular globals and hence
|
||||
this should be very fast in that case too.
|
||||
|
||||
Q. What happens in the module's top-level code where there is
|
||||
presumably no func_cells array?
|
||||
|
|
Loading…
Reference in New Issue