bpo-45697: Use PyObject_TypeCheck in type_call and binary_op1

[itamaro]

bpo-45697: Use PyObject_TypeCheck in type_call and binary_op1

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 implementation still walks the MRO.

Using PyObject_TypeCheck avoids calling PyType_IsSubtype in the common case.

This PR supersedes GH-29380 based on discussion on the issue https://bugs.python.org/issue45697

https://bugs.python.org/issue45697

[itamaro]

err, had a typo in the commit message with the issue number. happy to amend and push, though the devguide asks to avoid force pushing, so let me know what's the preferred way to edit that :-)

[serhiy-storchaka]

Creating a new type is relatively slow. I do not think that the effect of this nanooptimization is measureable.

[itamaro]

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 fast).

I ran some synthetic benchmarks with this change and without it (on an opt build with PGO and LTO), and the gain is measurable:

build from main (commit acc89db which is the base commit for this PR):

>for _ in {1..10}; do ./main-opt/python -m timeit -n 10000 -s 'class Spam: pass' -- 'ten_k_spams = [Spam() for _ in range(10000)]'; done
10000 loops, best of 5: 896 usec per loop
10000 loops, best of 5: 887 usec per loop
10000 loops, best of 5: 857 usec per loop
10000 loops, best of 5: 838 usec per loop
10000 loops, best of 5: 847 usec per loop
10000 loops, best of 5: 863 usec per loop
10000 loops, best of 5: 845 usec per loop
10000 loops, best of 5: 902 usec per loop
10000 loops, best of 5: 890 usec per loop
10000 loops, best of 5: 875 usec per loop

build with this change applied (commit 2362bf6):

>for _ in {1..10}; do ./test-opt/python -m timeit -n 10000 -s 'class Spam: pass' -- 'ten_k_spams = [Spam() for _ in range(10000)]'; done
10000 loops, best of 5: 833 usec per loop
10000 loops, best of 5: 885 usec per loop
10000 loops, best of 5: 845 usec per loop
10000 loops, best of 5: 838 usec per loop
10000 loops, best of 5: 833 usec per loop
10000 loops, best of 5: 827 usec per loop
10000 loops, best of 5: 858 usec per loop
10000 loops, best of 5: 811 usec per loop
10000 loops, best of 5: 843 usec per loop
10000 loops, best of 5: 845 usec per loop

also worth noting that the previous approach (GH-29380) was implemented on the Instagram Server production workload in Meta/Facebook/Instagram (choose your favorite) and resulted measurable perf gain of around 0.2%

[serhiy-storchaka]

Good point. Thank you for correcting me. Yes, for creating instances it makes more sense.

[serhiy-storchaka]

Good point. Thank you for correcting me. Yes, for creating instances it makes more sense.