[Guido]
> ...
> I think you're right that we might be able to use just a PyObject **; but
> I haven't fully digested Tim's more aggressive idea.)
The overwhelming thrust of Tim's variant is to reduce the (by far) most
frequent namespace operation to this:
case LOAD_GLOBAL_CELL:
cell = func_cells[oparg];
x = cell->objptr; /* note: not two levels, just one */
if (x != NULL) {
Py_INCREF(x);
continue;
}
... error recovery ...
break;
*Everything* else follows from that; it's really a quite minor variant of
the original proposal, consisting mostly of changes to spelling details due
to having a different kind of cell. The sole big change is requiring that
mutations to builtins propagate at once to their cached values in module
celldicts.
I believe Jeremy's scheme *could* do better than this for builtins, but not
the way it's currently set up (I don't see why we can't define a fixed
bijection between the standard builtin names and a range of contiguous
little integers, and use that fixed bijection everywhere; the compiler could
exploit this global (in the cross-module sense) bijection directly for
LOAD_BUILTIN offsets, eliminating all the indirection for standard builtins,
and eliminating the code-object-specific vectors of referenced builtin
names; note that I don't care about speeding access to builtins with
non-standard names -- fine by me if they're handled via LOAD_GLOBAL instead,
and fall into its "oops! it's not a module global after all" case).
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