Do you have any benchmark results to prove whether this is worth it?

I'd made a set of microbenchmarks for pattern matching. This change obviously only affects the first test subject (the dict). I've also included the second subject (an inexact dict) below for comparison.

• Without:

subject {'a': 'xxx', 1: 500} - time (μs): 1.29 1.28 1.28 1.29 1.28
subject D({'a': 'xxx', 1: 500}) - time (μs): 1.29 1.28 1.29 1.28 1.29
...

• With:

subject {'a': 'xxx', 1: 500} - time (μs): 1.05 1.04 1.05 1.04 1.06
subject D({'a': 'xxx', 1: 500}) - time (μs): 1.33 1.27 1.27 1.27 1.27
...

It's about a 20% speed up here. If I increase the number of keys to be tested so that the subject is {'a': 'xxx', 1: 500, 'b': 1, 'c': 2, 'd': 3} and the pattern is {"a": "xxx", A.b: x, "b": _, "c": _, "d": _, **extra} then the speed-up remains about 0.2 μs per call, suggesting that it's the constant work of getting subject.get and setting up the dummy object that's being eliminated.

So the benefit is probably "real, but not huge".

(I should add: I'm just compiling Python with make and no special C flags. The Python 3.10 version pre-installed on my system is notably quicker than both versions here, so I suspect I'm not getting the right compiler flags to really test it)

With --enable-optimizations --with-ltoI get:

With this change

subject {'a': 'xxx', 1: 500} - time (μs): 0.506 0.505 0.506 0.504 0.506
subject D({'a': 'xxx', 1: 500}) - time (μs): 0.593 0.596 0.594 0.594 0.597

and without

subject {'a': 'xxx', 1: 500} - time (μs): 0.569 0.574 0.574 0.577 0.578
subject D({'a': 'xxx', 1: 500}) - time (μs): 0.578 0.58 0.585 0.583 0.584

So a fairly similar level of speed-up.

I think this is heading in the wrong direction.
We should be improving the performance of pattern matching by producing better bytecode, not by making the interpreter more complex.

I think this is heading in the wrong direction. We should be improving the performance of pattern matching by producing better bytecode, not by making the interpreter more complex.

I agree at least in principle - I known @brandtbucher said he'd done some work on that. I was mainly proposing this PR as a fairly simple short-term improvement. But I'd ultimately expect it to be replaced with bytecode.

Please do reject it if you don't think the extra code is worth the improvement though.

I won't close this just yet.
We might choose to use it as a temporary measure, until the compiler generates better code for matching mappings.
@brandtbucher thoughts?