Open markshannon opened 1 year ago
Two of those we probably can't do away:
_PyObject_GetMethod (C API Call)
lookup_maybe_method (I forgot where this is from but I vaguely recall it being used by our internal C stuff too)
Also the biggest source of failures is actually loading attributes from managed dictionaries. Failures for "method" actually also counts failures for "has managed dict". So "has_managed_dict" is actually double counted! (We call SPEC_FAIL_ATTR_HAS_MANAGED_DICT, then SPEC_FAIL_ATTR_METHOD next).
I will work on this specialisation.
In case it matters, note that the pickle module (and copy) looks up __reduce__
, etc. on the object rather than on its type. That said, there is no tp_reduce
.
In case it matters, note that the pickle module (and copy) looks up
__reduce__
, etc. on the object rather than on its type. That said, there is notp_reduce
.
Yeah this is unavoidable in many modules. For example print
itself does one or two lookups (if I recall, one to sys.stdout
and another one elsewhere).
The stats show some 3.5 billion calls to
PyTypeLookup
(sum of all method cache hits and misses).Using this branch: https://github.com/faster-cpython/cpython/tree/type-cache-stats-plus I added a "why" field to all calls to
PyTypeLookup
Here are the results. I've add callers for the most common. The others can be found by looking at the above branch.
The 1.3B calls to
_PyObject_GenericGetAttrWithDict
are probably from unspecialized calls toLOAD_ATTR
. Improved specialization ofLOAD_ATTR
should remove most of them.The large number of calls to
type_getattro
is surprising and worth investigating, especially as each call totype_getattro
causes two calls toPyTypeLookup
.type_getattro
looks expensive.Method lookup also seems to be a source of lookups. Improved specialization of
LOAD_ATTR
should help here as well.