Add more optimizations #473
Merged
Conversation
This file contains 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
…eded to match a separated list
… to find the most expensive expression between 'rule' and 'rest'
dragostis
requested changes
Sep 22, 2020
dragostis
approved these changes
Sep 23, 2020
bors bot
added a commit
that referenced
this pull request
Sep 23, 2020
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>
|
Timed out. |
Merged
bors bot
added a commit
that referenced
this pull request
Oct 31, 2020
480: Fix build after PR #454 r=CAD97 a=SkiFire13 PR #454 broke the build by adding a doctest that doesn't compile, in particular it gave the following error: ``` failures: ---- src/error.rs - error::ErrorVariant<R>::message (line 445) stdout ---- error[E0282]: type annotations needed for `pest::error::ErrorVariant<R>` --> src/error.rs:447:15 | 5 | let variant = ErrorVariant::CustomError { | ------- ^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type for type parameter `R` declared on the enum `ErrorVariant` | | | consider giving `variant` the explicit type `pest::error::ErrorVariant<R>`, where the type parameter `R` is specified error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. Couldn't compile the test. failures: src/error.rs - error::ErrorVariant<R>::message (line 445) test result: FAILED. 59 passed; 1 failed; 2 ignored; 0 measured; 0 filtered out ``` This error made PRs #470's and #473's bors build fail. After this PR is merged bors should be re-run for them. Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com>
|
I'll re-r this once CI is fixed (#483), but I unfortunately really don't have time to sort through the new style warnings and apply/ignore them right now. I already spent too much time on this, grad school is really eating all of my time |
CAD97
requested changes
Oct 31, 2020
CAD97
approved these changes
Nov 1, 2020
bors bot
added a commit
that referenced
this pull request
Nov 1, 2020
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>
|
Timed out. |
|
bors merge |
|
Build succeeded: |
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.
Adds a couple more optimizations:
Converts
(rule ~ rest) | ruletorule ~ rest?, avoiding trying to matchruletwice. Same as the already existingfactorbut in the case the second expression is notExpr::Seq.Converts
rule | (rule ~ rest)torulesince(rule ~ rest)will never match ifruledidn't. Not sure if this should go infactorizer.rsbut the pattern looked really similar.Converts
(rule ~ rest)* ~ ruletorule ~ (rest ~ rule)*, avoiding matching the lastruletwice, should have a big impact on issues like Improving slow Rockstar parser #453 and Very slow recursive pattern #463. Goes to a new file nameslister.rs, not sure if the name is descriptive enough.Actually there's a 4th optimization I thought of, converting
(rule ~ rest)* ~ rule?torule ~ (rest ~ rule)* ~ rest?, assumingruleis more expensive thanrestbut I don't think this can be determined if one of them contain anExpr::Ident. This would have the same effect of 3. on the relevant cases.