gh-89013: Improve the performance of methodcaller (lazy version)

[eendebakpt]

This is a variation on #106960 where the allocation of the structures required for the vectorcall is delayed untill the first invocation of the methodcaller. The advantage is that that for methodcaller objects that are created, but never used, the creation time and amount of memory used is the same as current main.

Benchmark results:

call: Mean +- std dev: [main] 136 ns +- 1 ns -> [pr_lazy] 58.3 ns +- 1.4 ns: 2.34x faster
creation: Mean +- std dev: [main] 98.7 ns +- 3.4 ns -> [pr_lazy] 95.7 ns +- 3.2 ns: 1.03x faster
creation+call: Mean +- std dev: [main] 255 ns +- 9 ns -> [pr_lazy] 186 ns +- 6 ns: 1.37x faster
call kwarg: Mean +- std dev: [main] 217 ns +- 3 ns -> [pr_lazy] 85.9 ns +- 2.4 ns: 2.53x faster
creation kwarg: Mean +- std dev: [main] 166 ns +- 4 ns -> [pr_lazy] 170 ns +- 5 ns: 1.02x slower
creation+call kwarg: Mean +- std dev: [main] 386 ns +- 13 ns -> [pr_lazy] 339 ns +- 4 ns: 1.14x faster
Geometric mean: 1.45x faster

Benchmark script

import pyperf
setup = """
from operator import methodcaller as mc
arr = []
call = mc('sort')
call_kwarg = mc('sort', reverse=True)
"""
runner = pyperf.Runner()
runner.timeit(name="call", stmt="call(arr)", setup=setup)
runner.timeit(name="creation", stmt="call = mc('sort')", setup=setup)
runner.timeit(name="creation+call", stmt="call = mc('sort'); call(arr)", setup=setup)
runner.timeit(name="call kwarg", stmt="call_kwarg(arr)", setup=setup)
runner.timeit(name="creation kwarg", stmt="call = mc('sort', reverse=True)", setup=setup)
runner.timeit(name="creation+call kwarg", stmt="call = mc('sort', reverse=True); call(arr)", setup=setup)

• Issue: Could operator.methodcaller be optimized using LOAD_METHOD? #89013

[corona10]

How is methodcaller well used? Often converting to the vectorcall requires maintenance cost, so you need to justify increasing the code complexity.

[eendebakpt]

@corona10 The PR indeeds adds some additional code (the methodcaller_vectorcall is small, the initialization code a bit larger), but it is not a lot of code. If maintenance is a concern, I can try rewrite the code to keep the additions to a minimum. (in this PR I added some code because of an earlier concern of added memory usage)

• In the orignal PR bpo-44850: Improve the performance of methodcaller. #27782 there is some motivation
• The methodcaller is a method used in many projects: https://github.com/search?q=operator.methodcaller&type=code (7.5k hits) and https://github.com/search?q=%22from+operator+import+methodcaller%22&type=code (3.1k hits)
• Personally, I prefer the methodcaller over anonymous methods. In particular when arguments are variable. E.g. methodcaller('sort') and lambda x: x.sort() are similar to write. But if there is a variable w (int), we can write f=methodcaller('pop', w). The lambda looks like f=lambda x, p=w : x.pop(p), which looks much less nice to me

But comparing performance and maintenance costs is a bit like comparing apples and oranges, so it it up to you (and other core devs) to make a decision here.

[corona10]

Why did you separate the function?
Please, just inline the function in here if there is no specific reason.

[eendebakpt]

To make it more symmetric with the _methodcaller_initialize_vectorcall. I will inline here. Let me know if the _methodcaller_initialize_vectorcall should also be inlined.

[corona10]

I left some minor comments, I will take a look at this PR more.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @corona10 for commit d70a8ad 🤖

If you want to schedule another build, you need to add the 🔨 test-with-refleak-buildbots label again.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @corona10 for commit 812856b 🤖

If you want to schedule another build, you need to add the 🔨 test-with-refleak-buildbots label again.

[corona10]

LGTM

Let's see the result of refleak tests.

[corona10]

Leak tests are unrelated to this PR.

[vstinner]

Nice optimization.