-
-
Notifications
You must be signed in to change notification settings - Fork 261
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Very slow recursive pattern #463
Comments
When parsing
|
Thank you for this issue. it was a very helpful example of a recursive pattern. You have helped me get unstuck! |
473: Add more optimizations r=dragostis a=SkiFire13 Adds a couple more optimizations: 1. Converts `(rule ~ rest) | rule` to `rule ~ rest?`, avoiding trying to match `rule` twice. Same as the already existing `factor` but in the case the second expression is not `Expr::Seq`. 2. Converts `rule | (rule ~ rest)` to `rule` since `(rule ~ rest)` will never match if `rule` didn't. Not sure if this should go in `factorizer.rs` but the pattern looked really similar. 3. Converts `(rule ~ rest)* ~ rule` to `rule ~ (rest ~ rule)*`, avoiding matching the last `rule` twice, should have a big impact on issues like #453 and #463. Goes to a new file names `lister.rs`, not sure if the name is descriptive enough. Actually there's a 4th optimization I thought of, converting `(rule ~ rest)* ~ rule?` to `rule ~ (rest ~ rule)* ~ rest?`, assuming `rule` is more expensive than `rest` but I don't think this can be determined if one of them contain an `Expr::Ident`. This would have the same effect of 3. on the relevant cases. Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com>
473: Add more optimizations r=dragostis a=SkiFire13 Adds a couple more optimizations: 1. Converts `(rule ~ rest) | rule` to `rule ~ rest?`, avoiding trying to match `rule` twice. Same as the already existing `factor` but in the case the second expression is not `Expr::Seq`. 2. Converts `rule | (rule ~ rest)` to `rule` since `(rule ~ rest)` will never match if `rule` didn't. Not sure if this should go in `factorizer.rs` but the pattern looked really similar. 3. Converts `(rule ~ rest)* ~ rule` to `rule ~ (rest ~ rule)*`, avoiding matching the last `rule` twice, should have a big impact on issues like #453 and #463. Goes to a new file names `lister.rs`, not sure if the name is descriptive enough. Actually there's a 4th optimization I thought of, converting `(rule ~ rest)* ~ rule?` to `rule ~ (rest ~ rule)* ~ rest?`, assuming `rule` is more expensive than `rest` but I don't think this can be determined if one of them contain an `Expr::Ident`. This would have the same effect of 3. on the relevant cases. Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com>
473: Add more optimizations r=MarinPostma a=SkiFire13 Adds a couple more optimizations: 1. Converts `(rule ~ rest) | rule` to `rule ~ rest?`, avoiding trying to match `rule` twice. Same as the already existing `factor` but in the case the second expression is not `Expr::Seq`. 2. Converts `rule | (rule ~ rest)` to `rule` since `(rule ~ rest)` will never match if `rule` didn't. Not sure if this should go in `factorizer.rs` but the pattern looked really similar. 3. Converts `(rule ~ rest)* ~ rule` to `rule ~ (rest ~ rule)*`, avoiding matching the last `rule` twice, should have a big impact on issues like #453 and #463. Goes to a new file names `lister.rs`, not sure if the name is descriptive enough. Actually there's a 4th optimization I thought of, converting `(rule ~ rest)* ~ rule?` to `rule ~ (rest ~ rule)* ~ rest?`, assuming `rule` is more expensive than `rest` but I don't think this can be determined if one of them contain an `Expr::Ident`. This would have the same effect of 3. on the relevant cases. Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com>
I had a similar performance issue with rules of the form One more issue that caused exponential parsing time was in the form of It is quite hard to find those when there is some nesting and indirection. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Parsing this expr(ession)
a(b,{a(b,{a(b,{a(b,{a(b,{a(b,{a(b,{a(b,{})})})})})})})})
with this grammar
is extremely slow (takes multiple minutes, and gets exponentially slower as you add more recursion).
The text was updated successfully, but these errors were encountered: