Repository navigation
gh-153568: Skip the expression precedence chain for single-token atoms - #153575
Merged
Merged
Conversation
pablogsal
force-pushed
the
gh-153568-atom-fastpath
branch
4 times, most recently
from
July 11, 2026 14:39
f3cc7e4 to
24e869c
Compare
pablogsal
force-pushed
the
gh-153568-atom-fastpath
branch
2 times, most recently
from
July 11, 2026 15:29
b3a8d8f to
605c6d7
Compare
pablogsal
changed the title
pablogsal
force-pushed
the
gh-153568-atom-fastpath
branch
2 times, most recently
from
July 11, 2026 15:46
26282a7 to
61277c2
Compare
pablogsal
changed the title
pablogsal
force-pushed
the
gh-153568-atom-fastpath
branch
from
September 14, 2026 20:50
61277c2 to
5616907
Compare
Contributor
|
Sorry, incorrectly flagged as a duplicate. |
lysnikolaou
reviewed
Oct 22, 2026
lysnikolaou
left a comment
lysnikolaou
left a comment
Member
There was a problem hiding this comment.
This is a great idea! Left a few comments inline.
Member
Author
|
pablogsal
force-pushed
the
gh-153568-atom-fastpath
branch
from
October 23, 2026 19:00
7dac9d1 to
0136cf5
Compare
Member
Author
|
@lysnikolaou can you take another look? |
lysnikolaou
approved these changes
Oct 23, 2026
…n atoms A bare name or number followed by a token that cannot extend an expression is now built directly, avoiding a dozen rule invocations per atom. Rules declare the hook with the new (fastpath=function) flag next to (memo); the generator only emits the hook call and knows nothing about tokens or expressions.
Co-authored-by: Lysandros Nikolaou <lisandrosnik@gmail.com>
Expose memo and fastpath attributes for the C generator and simplify the atom fast-path comment.
pablogsal
force-pushed
the
gh-153568-atom-fastpath
branch
from
October 23, 2026 20:17
8b90c67 to
ef620c0
Compare
pablogsal
enabled auto-merge (squash)
October 23, 2026 20:17
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Parsing a bare name or number descends the whole expression precedence chain (about 14 rule invocations plus their memoization traffic) just to wrap one token in a node, and that shape dominates real code through call arguments, assignments and subscripts. When the next token cannot start or continue an expression the result is provably that single atom, so the chain entry rules now build it directly, leaving the token fill state exactly as before so error locations are unaffected.
Rules declare the hook in the grammar with a new
(fastpath=function)flag next to(memo), so the generator only emits the hook call and knows nothing about tokens or expressions; the atom logic lives with the other token helpers in pegen.c, and the mechanism is documented with a worked example in InternalDocs/parser.md. Candidate hooks on more chain rules, assignment targets and subscript slices were measured individually and dropped: none cleared 0.4%, and hooking every chain level measured 6% slower from the per-entry decline checks.Benchmark (parsing 8 of the largest stdlib files, 1.3 MB, 20 times per run with
_PyParser_ASTFromString— parser only, no AST-to-Python conversion; pyperf, interleaved runs):