-
Notifications
You must be signed in to change notification settings - Fork 66
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
Optimize redundant fail checks #118
Conversation
999aba1
to
0afeb61
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Creating a good PR is not a simple task, yes. I don't think we should rush to merge unpolished PRs.
The difference, of course, is I'm able to say specifically what isn't acceptable, and why.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@StoneCypher, thanks for review! I'll add some comments describing the overall idea of the generate-bytecode
pass, I hope, that saves your time for the next time
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
0afeb61
to
913b3f2
Compare
I've add some comments, explaining some details how the Ready for final review. |
This comment has been minimized.
This comment has been minimized.
913b3f2
to
52ed2d2
Compare
ccf2d2c
to
19a1a50
Compare
19a1a50
to
36e9b07
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are all minor comments. One substantive point of discussion, though: shouldn't many of these cases be warnings (or errors if you pass in a "all warnings are errors" flag)? We don't currently have a mechanism for warnings, but if we're going to do multiple errors in #160, could we discuss also adding warnings at the same time?
@@ -248,7 +269,10 @@ function generateBytecode(ast) { | |||
return first.concat(...args); | |||
} | |||
|
|||
function buildCondition(condCode, thenCode, elseCode) { | |||
function buildCondition(match, condCode, thenCode, elseCode) { | |||
if (match > 0) { return thenCode; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you add constants, they should be used here as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Locally fixed all except constants. Will do that tomorrow.
Yes, always matched/never matched will report warnings when we merge warnings support. |
…or result of parse, when it can be statically determined The idea in that we calculate expected rules result and use that information when generate bytecode. Some constructs of the PEG grammar never fail, for example, optional operator `?` or repetition operator `*`. So it is unnecessary to check their result for the failure. New pass `inference-match-result.js` adds to the each AST node new integer property `match`, which represents possible result of matching: - `<0` - node is never match, for example, `!('a'*)` (negation of the always matched node) - `=0` - sometimes node matched, sometimes not. This is behavior before that change - `>0` - node is always matched, for example, `'a'*` (because result is or empty array, or array with some elements)
…hangelog (review this change with the space changes ignored)
36e9b07
to
8a4051f
Compare
@@ -248,7 +270,10 @@ function generateBytecode(ast) { | |||
return first.concat(...args); | |||
} | |||
|
|||
function buildCondition(condCode, thenCode, elseCode) { | |||
function buildCondition(match, condCode, thenCode, elseCode) { | |||
if (match === ALWAYS_MATCH) { return thenCode; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reads a lot easier. thanks for that.
I went to add type tests for MatchResult, and found an error in the compile interface of peg.d.ts. Here's an appended patch that fixes that, and adds the comment I was talking about. Let me know your opinion, please. |
…oesn't need to be an object that gets converted to an array; it can just be an array that gets copied
…er to generate MatchResult
ed1cb08
to
3a25229
Compare
Ok. I've just split you commit into two and fix a small incorrectness in you understanding of a situation about possible cycle |
Port of my optimization pegjs/pegjs#400, that reduce many dumb comparisons (that is not cut by minifiers). You can see some of them on the
parser.js
(but enable whitespace-ignored mode on github)I calculate possible values of the match result and do not generate conditions, that are always
true
orfalse
and also didn't generate not used constants.