gh-138912: Add fast path for match class patterns without sub-patterns

[cdce8p]

Extracted from #139080. This builds on the work merged with 75d4839.

Add a fast path for match class patterns without any sub-patterns. This avoids creating a new (empty) tuple, pushing it to the stack and subsequently unpacking the tuple result from the MATCH_CLASS opcode again.

__
Micro benchmarks with all specializations enabled.

Micro benchmark (bare class pattern)

from timeit import timeit
setup = """
class A:
    def __init__(self, x, y):
        self.x = x
        self.y = y
a = A(1, 2)

def f1(a):
    if isinstance(a, A):
        return True
    return False

def f2(a):
    match a:
        case A():
            return True
    return False
"""
print(f"If\t{timeit("f1(a)", setup, number=10**7)}")
print(f"Match\t{timeit("f2(a)", setup, number=10**7)}")

# Before
If      0.2718
Match   0.2659

# After
Match   0.2253 -15.27%

If specialization disabled, the performance improvement is even better with -37.44%.

• Issue: Performance improvements for the MATCH_CLASS opcode #138912

---

📚 Documentation preview 📚: https://cpython-previews--144820.org.readthedocs.build/

[markshannon]

Opcodes are a very limited resource, so we need to justify it carefully when adding new ones.

Is pattern matching widely used enough yet to justify this? I don't know.
Is the performance increase enough to justify adding a new instruction?

---

An approach to optimizing pattern matching that I would be more enthusiastic about is optimizing the decision tree.
This will still need new instructions, but they would be smaller and more easily optimized.

For example, case A(a, b) does both an instance check, and unpacks into a and b, so

match m:
    case A(a, b):
        X
    case A():
       Y

can be transformed into the decision tree, like this:

if m isa A:
    if tmp := unpack_attributes(m, 2):
        a, b = tmp
        X
    else:
        Y

which can be converted into code that has simpler operations and is more amenable to further specialization/jitting.

[eendebakpt]

Inspired by Mark's comments I looked at the generated bytecode:

def g(m):
    match m:
        case A():
            return 100
    return None
import dis
print(dis.dis(g))

Output:

  2           RESUME                   0

  3           LOAD_FAST                0 (m)

  4           LOAD_GLOBAL              0 (A)
              LOAD_CONST               1 (())
              MATCH_CLASS              0
              COPY                     1
              POP_JUMP_IF_NONE         3 (to L1)
              UNPACK_SEQUENCE          0

  5           RETURN_CONST             2 (100)

  4   L1:     POP_TOP

  6           RETURN_CONST             0 (None)
None

This can be simplified to (diff main...eendebakpt:pattern_match_class_v0)

  8           RESUME                   0

  9           LOAD_FAST_BORROW         0 (m)

 10           LOAD_GLOBAL              0 (A)
              LOAD_CONST               0 (())
              MATCH_CLASS              0
              POP_JUMP_IF_FALSE        3 (to L1)
              NOT_TAKEN

 11           LOAD_SMALL_INT         100
              RETURN_VALUE

 12   L1:     LOAD_CONST               1 (None)
              RETURN_VALUE
None

A quick benchmarks shows this is a bit faster.

I tried changing the bytecode generation to use an isinstance check instead of MATCH_CLASS, but that turns out to be slower (even when adding isinstance to the LOAD_COMMON_CONSTANT). Maybe this can be made faster (also for the multi argument case), but that would require some more work.

[cdce8p]

Is pattern matching widely used enough yet to justify this? I don't know. Is the performance increase enough to justify adding a new instruction?

Is it widely used, probably not. However, I'd guess that's mostly because support for Python 3.9 was only dropped at the end of last year. So most projects didn't have the option to start adopting it before then. Furthermore it's unlikely that developers go through existing code bases just to look for good opportunities to replace existing if-statements with match. I did it for pylint, just because I was curious, e.g. pylint-dev/pylint#10529. Sure this refactor is mostly unnecessary but while doing so, I noticed that especially the class pattern can be quite useful. E.g. I replaced this

# old
if isinstance(var, A):
    ...
elif isinstance(var, B):
    ...
elif isinstance(var, C):
    ...

# new
match var:
    case A():
        ...
    case B():
        ...
    case C():
        ...

We ended up keeping it and I've seen a similar PR proposed for pytest. What I did realize though was that I inadvertently ended up introducing a noticeable performance regression, roughly 7-10% for the whole program, on Python 3.13. That's what lead me down the path of exploring how it can be speed up, first with #138915 and now here.

Approach / Implementation

Since class patterns are so useful, I'd like to make them as fast as possible. Ideally so that there isn't a real difference between equivalent if and match statements. To archive that I'd like to eliminate the intermediary tuple completely, at least if only keyword patterns are used. This will change the evaluation from BFS to DFS but I think that is an acceptable tradeoff. To do that however, I'll need two new opcode. First the MATCH_CLASS_ISINSTANCE added here and then another one to get the optional attributes MATCH_CLASS_GET_OPT_ATTR. You can view the full change in #139080.

An approach to optimizing pattern matching that I would be more enthusiastic about is optimizing the decision tree. This will still need new instructions, but they would be smaller and more easily optimized.

I'd consider something like that shortly as I was checking if there are ways to cache the results of the isinstance check in class patterns. Didn't investigate it further though.

--
@eendebakpt Thanks for the suggestion! If the decision is against adding new opcodes, this would be a fallback option. Do note however that an empty tuple is still created (the singleton lookup) placed onto the stack, popped for MATCH_CLASS, created and pushed to the stack again before it needs to be pooped in codegen_pattern_class before returning the result.

[eendebakpt]

-- @eendebakpt Thanks for the suggestion! If the decision is against adding new opcodes, this would be a fallback option. Do note however that an empty tuple is still created (the singleton lookup) placed onto the stack, popped for MATCH_CLASS, created and pushed to the stack again before it needs to be pooped in codegen_pattern_class before returning the result.

I agree, my suggestion is indeed a fallback if opcodes are too scarce. Another possibility to avoid creation of new opcodes might be to make use of the CALL_INTRINSIC_2 opcode. The functionality of the MATCH_CLASS_ISINSTANCE from this PR could be rewritten to an intrinsic method called via CALL_INTRINSIC_2 as the stack effects are the same. (disclaimer: I am not sure how fast it would be, and not sure whether the PyType_Check from the MATCH_CLASS_ISINSTANCE can be handled)

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #33469151 | 📁 Comparing 53fd8f4 against main (d36e5b8)

  🔍 Preview build  

210 files changed · + 3 added · ± 206 modified · - 1 deleted

+ Added

• deprecations/pending-removal-in-3.21.html
• howto/abi3t-migration.html
• library/asyncio-threading.html

± Modified

• bugs.html
• glossary.html
• index.html
• py-modindex.html
• c-api/bytes.html
• c-api/complex.html
• c-api/coro.html
• c-api/dict.html
• c-api/exceptions.html
• c-api/extension-modules.html
• and 196 more...

- Deleted

• library/asyncio-policy.html

[cdce8p]

Update the PR to use INTRINSIC_2 following the comment from @eendebakpt in #139080 (comment). The performance is comparable and this avoids creating a new opcode just for the isinstance call in class patterns. For more details see my response #139080 (comment).

[eendebakpt]

@cdce8p Thanks for the update. On a technical level this looks good and it does not use any new opcodes.

I did a quick benchmark on my system and found this PR (at commit 53fd8f4) to be about 20% faster (in line with the OP). A simpler approach (main...eendebakpt:pattern_match_class_v0) gives a 10% gain. If these numbers hold, I am leaning a bit towards the simpler approach.

@markshannon

[cdce8p]

Thanks for taking the time to look at it @eendebakpt!

I did a quick benchmark on my system and found this PR (at commit 53fd8f4) to be about 20% faster (in line with the OP). A simpler approach (main...eendebakpt:pattern_match_class_v0) gives a 10% gain. If these numbers hold, I am leaning a bit towards the simpler approach.

While the concrete performance difference between the two solutions might be minimal in practice, I'd still like to argue in favor of CALL_INTRINSIC_2 here. My ultimate goal would be to optimize class patterns with only keywords as well, that's where it all started in #139080 after all. Using the call intrinsic here will be easier to reuse. In the end the (full) changes might look like this: main...cdce8p:cpython:match-class-opcode-intrinsic-2. Not only do we get 15-20% for bare class patterns, but also around a 30% improvement for keyword only class patterns which are comparably slower at the moment.

match a:
    case A(x=1): ...

A point of comparison for why I think it's worth it. Last year I added a few match statement in pylint. One of the ideal projects to use the match statement IMO. A few stats:

• 183 total number of match statement
• 396 match cases
• 454 class patterns, of those 207 are bare, 245 keyword only and 2 positional and/or mixed
• Other pattern types
  • 207 AS
  • 46 OR
  • 26 singleton
  • 84 value
  • 72 sequence
  • 15 star
  • 1 mapping

While this is only one project which itself isn't representative, the class pattern is used by far the most. So I believe it makes sense to optimize it and even an additional 5-10% is still a good improvement in the end. Looking at the stats, it might also be obvious why I want to focus on keyword only class patterns as well.