Add Ping's "always doubly-indirect" idea. Remove mistaken pseudo-C

for Tim's ideal.
This commit is contained in:
Guido van Rossum 2002-02-11 16:24:10 +00:00
parent 6a826bf8aa
commit d4757ee5a2
1 changed files with 13 additions and 8 deletions

View File

@ -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?