Change parsing from exponential to linear - #410
Merged
apoelstra merged 2 commits intoSep 4, 2026
Conversation
A combinator parser can silently parse the same sub-tree more than once, wherever
two alternatives can both begin at the current token and the choice between them
is only settled after the whole sub-tree has been consumed. One such spot doubles
the work for every level of nesting. Ordinary programs nest a handful of levels
deep, so it shows up there as a small constant factor and nothing in the test
suite notices, while a program a few hundred bytes long takes minutes to parse.
Add a harness that measures each way the grammar can nest -- blocks,
parentheses, and option, tuple and array types -- by parsing each to increasing
depths and reporting how the cost grows:
cargo test --test parser_scaling -- --ignored --nocapture
It is ignored by default because it times the parser, and timings are too noisy
to gate CI on. It is meant as an instrument to reach for when touching the
grammar, and wants a new case whenever the grammar grows a new way to nest.
Measuring every construct before asserting anything means a failure names which
rule is at fault rather than only that something is slow. Against the parser as
it stands, four of the five constructs are flat and blocks are not:
blocks 160.5x TOO STEEP
parentheses 1.2x ok
option types 1.4x ok
tuple types 1.4x ok
array types 1.3x ok
The blocks column grows by a factor converging on 4 across every two levels,
which is the doubling per level. The next commit parses each element of a block
body once, after which blocks measure 1.3x alongside the rest.
Contributor
Author
|
Unfortunately, for #401 this PR only increases the max nesting from 16 to 32, so more work is needed. |
Contributor
FWIW I think that the commit message in ec211c2 does a good job. In ec211c2 I think you should remove the |
Contributor
|
ec211c2 looks good other than that I think you should unignore the test. Honestly the new code is easier to follow than the old (once you look up what I might suggest adding type annotations to most of the |
A block body was parsed as "statements, then an optional final expression", which are two parsers that both start at the same token. Every element of a block was therefore parsed twice: once as a statement, which only fails after the whole element has been consumed and no `;` turns up, and then again as the final expression. That doubles the work for each level of block nesting, so parsing is exponential in how deeply a program nests blocks. Measured on a release build before this change, a program that nests nothing but blocks takes 315ms at depth 16, 5.5s at depth 20 and 82s at depth 24, and does not finish within five minutes at depth 28. Any service that compiles submitted .simf files can be stalled by a few hundred bytes of input. Parse each element once instead and decide what it was from the `;` that follows it: only the last element may drop its `;`, and only when it is an expression rather than an assignment, in which case it is the block's final expression. A missing `;` anywhere else is reported and the element is kept as a statement, so the rest of the block is still analyzed. The same nesting now parses in 2ms at depth 24 and 18ms at depth 512.
stringhandler
force-pushed
the
st-parse-linear
branch
from
September 3, 2026 13:45
ec211c2 to
e2530af
Compare
Contributor
Author
|
Updated. The test runs quicker than some others. |
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
2 participants
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.
In an attempt to increase the nesting limit in #401, an LLM found this incredibly subtle bug in statements parsing.
It's difficult to explain why this works, basically it would match a block body, then fail and parse each statement again. I've left the extraneous descriptions in the commits, but happy to remove them.
There are two commits.
Commit 1 adds an ignored test that shows the problem. Run it with
cargo test --test parser_scaling -- --ignored --nocaptureCommit 2 adds the fix that converts it from exponential to linear. Run the test again afterwards to see the improvement.
Here are some figures from my computer:
After