GeezerVison

Summary

Collapse runs of adjacent LITERAL opcodes into one _sre dispatch.

In SRE(match), SRE_OP_LITERAL and SRE_OP_LITERAL_IGNORE each matched one character and then went back to the computed-goto dispatch. This change loops while the next opcode is the same literal opcode, so a run of N literal characters costs one dispatch instead of N.

Matching behavior is unchanged. The loop reads the next opcode right after each literal, which the old code did not do. That read stays in bounds because every compiled SRE pattern ends with SUCCESS or FAILURE.

Files: Modules/_sre/sre_lib.h

What we gain

Each literal character in a pattern is one opcode, and before this change each one paid a full dispatch. Patterns with long literal runs ("Content-Length: ", (\d+) bytes received, foo|bar|baz) now match those runs in a tight loop. Patterns made of classes and repeats (\w+, .*?) are unaffected.

Measured

pyperformance regex benchmarks, before vs after, compared with pyperf compare_to:

• AMD and Apple: faster on all three benchmarks, about 4% on AMD and 9–10% on Apple.
• Intel: faster on regex_effbot (+3.5%) and regex_dna (+2.2%), but 1.2% slower on regex_v8. regex_v8 uses many short patterns with few literal runs, so the extra opcode read in the new loop isn't paid back there on this CPU.
• Overall, 8 of 9 results are significant gains, and the one slowdown is small.

Test plan

• Regex tests: test_re passes on latest main with the patch.
• Accuracy: identical match results on 87,222 regex cases, before vs after.
• Timing: pyperformance regex_v8, regex_effbot, regex_dna on all three machines (table above).

• Issue: Speed up _sre matching of runs of literal characters #161335