homepage

PyTuple_Check() got slower across the board. This is problematic because the principal use case for PyTuple_Check() is as a guard for various fast paths.
The direct cause of the degradation is that the inlining of PyType_Check() didn't go so well — commit 509dd90f4684e40af3105dd3e754fa4b9c1530c1. 
There are two issues. First, we lost the fast path for an exact type match that was present in the 3.8 version of PyType_Check(). Second, functions like PyType_Check() cannot be fully inlined if they call other non-inlined functions like PyType_GetFlags().
The original unreviewed commit doesn't revert cleanly because subsequent changes were made. Instead, I suggest:
* restore the short-cut for an exact type match, and
* convert PyType_GetFlags() to a macro or an inlined function
That would fix the performance regression while still treating type objects as opaque.
------- Incomplete inlines ----------------------------------------------
------- line 639 in object.h --------------------------------------------
static inline int
PyType_HasFeature(PyTypeObject *type, unsigned long feature) {
 return ((PyType_GetFlags(type) & feature) != 0);
}
 ^---- Non-static function cannot be inlined
#define PyType_FastSubclass(type, flag) PyType_HasFeature(type, flag)
static inline int _PyType_Check(PyObject *op) {
 return PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_TYPE_SUBCLASS);
}
#define PyType_Check(op) _PyType_Check(_PyObject_CAST(op))
------- Old Type Check Code ---------------------------------------------
------- line 646 in object.h --------------------------------------------
#define PyObject_TypeCheck(ob, tp) \
 (Py_TYPE(ob) == (tp) || PyType_IsSubtype(Py_TYPE(ob), (tp)))
 ^--- Fast path for exact match is now gone
------- Non-static function cannot be inlined --------------------------
------- line 2339 in typeobject.c -------------------------------------
unsigned long
PyType_GetFlags(PyTypeObject *type)
{
 return type->tp_flags;
}