[issue45697] PyType_IsSubtype is doing excessive work in the common case

Serhiy Storchaka added the comment: Thank you for your contribution Itamar. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue45697] PyType_IsSubtype is doing excessive work in the common case

Serhiy Storchaka added the comment: New changeset 2c045bd5673d56c3fdde7536da9df1c7d6f270f0 by Itamar Ostricher in branch 'main': bpo-45697: Use PyObject_TypeCheck in type_call (GH-29392) https://github.com/python/cpython/commit/2c045bd5673d56c3fdde7536da9df1c7d6f270f0 --

[issue45697] PyType_IsSubtype is doing excessive work in the common case

Itamar Ostricher added the comment: thanks for the feedback Serhiy! repeating my response from the PR here as well (not sure what's the proper etiquette.. :-) ) note that this code path is not for creating new types (which is slow as you say), but for creating new instances (which is quite

[issue45697] PyType_IsSubtype is doing excessive work in the common case

Serhiy Storchaka added the comment: Creating a new type takes microseconds, and using PyObject_TypeCheck() instead of PyType_IsSubtype() can save nanoseconds. So, while this replacement looks harmless, its effect can hardly be measured even in microbenchmarks. --

[issue45697] PyType_IsSubtype is doing excessive work in the common case

Itamar Ostricher added the comment: thanks for the feedback & discussion, I submitted a new PR -- ___ Python tracker ___ ___

[issue45697] PyType_IsSubtype is doing excessive work in the common case

Change by Itamar Ostricher : -- pull_requests: +27650 pull_request: https://github.com/python/cpython/pull/29392 ___ Python tracker ___

[issue45697] PyType_IsSubtype is doing excessive work in the common case

Ken Jin added the comment: > Dennis, you mean something like this? > https://github.com/itamaro/cpython/commit/92d46b260cf6ccce1a47003f539294530138e488 Not Dennis, but these changes looks good. As Serhiy mentioned, we can replace the hot callsites with PyObject_TypeCheck without slowing

[issue45697] PyType_IsSubtype is doing excessive work in the common case

Serhiy Storchaka added the comment: The PyObject_TypeCheck() macro is used in performance critical cases. If it is not the case the PyType_IsSubtype() function can be used. Adding yet check in PyType_IsSubtype() will slow down more performance sensitive cases in which PyObject_TypeCheck()

[issue45697] PyType_IsSubtype is doing excessive work in the common case

Oleg Iarygin added the comment: Dennis, can PyFrozenSet_Check and _PyObject_TypeCheck get rid of Py_IS_TYPE invocation then, so PyType_IsSubtype becomes the only source of truth here? -- nosy: +arhadthedev ___ Python tracker

[issue45697] PyType_IsSubtype is doing excessive work in the common case

Itamar Ostricher added the comment: Dennis, you mean something like this? https://github.com/itamaro/cpython/commit/92d46b260cf6ccce1a47003f539294530138e488 sure, that would preempt the `PyType_IsSubtype` calls coming from these specific callsites, but the early return in `PyType_IsSubtype`

[issue45697] PyType_IsSubtype is doing excessive work in the common case

Dennis Sweeney added the comment: Interesting. It seems like several call sites already check the equality case: setobject.h: #define PyFrozenSet_Check(ob) \ (Py_IS_TYPE(ob, _Type) || \ PyType_IsSubtype(Py_TYPE(ob), _Type)) object.h: static inline int

[issue45697] PyType_IsSubtype is doing excessive work in the common case

Change by Itamar Ostricher : -- keywords: +patch pull_requests: +27638 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29380 ___ Python tracker

[issue45697] PyType_IsSubtype is doing excessive work in the common case

New submission from Itamar Ostricher : Based on real world profiling data we collected, a vast amount of `PyType_IsSubtype` calls are coming from `type_call`, when it decides whether `__init__` should run or not. In the common case, the arguments to this call are identical, but the