Optimize generated parser inlining - #318
Merged
Merged
Conversation
Apply aggressive inlining to generated parser wrappers and selectively to small generated methods, avoiding code growth for larger parser bodies. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 096afb8d-6bc6-4ba9-9af3-1602a00a2cf0
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
1 participant
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.
Generated combinator parsers pay a measurable cost for their helper-heavy call structure. Email parser benchmarks showed that JIT inlining can recover about 10.9% of that overhead, reducing the generated Parlot parser from 67.15 ns to 59.84 ns.
This change always marks the trivial generated parser wrapper for aggressive inlining and selectively applies the same hint to core, deferred, and helper methods with no more than 24 emitted local/body statements. The size gate preserves the measured benefit of blanket inlining while avoiding the code-size and instruction-cache risks of forcing large generated methods inline.
Regression coverage verifies that small hot-path methods receive the attribute while a larger generated choice core does not.