Skip to content
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 silent fails: remove checks that always false #399

Merged
merged 3 commits into from Jan 1, 2018

Conversation

Mingun
Copy link
Contributor

@Mingun Mingun commented Jan 17, 2016

The first сommit removed unnecessary checks with peg$silentFails if earlier in the parse function for the rule this variable was incremented. The second commit extends optimization for boundaries of rules: if rule always used in context of suppressed failure generation (there three of such context -- rules under named, simple_and and simple_not AST nodes) checks aren't generated.

The size of the generated parsers slightly decreased, and speed, most likely, didn't change though it would be worth expecting small improving. Measurements yield contradictory results, here the most noticeable of them with deviations in both sides (from 7 carried-out tests, in remaining distinction sticks near +/-0.5%, master is 48f5ea4):

$ ./impact master optimize-silent-fails
Measuring commit master... OK
Measuring commit optimize-silent-fails... OK

Speed impact
------------
Before:     164.95 kB/s
After:      141.32 kB/s
Difference: -14.33%

Size impact
-----------
Before:     721705 b
After:      646518 b
Difference: -10.42%

(Measured by /tools/impact with Node.js v0.10.18 on MINGW32_NT-6.0 1.0.18(0.48/3/2) i686.)
$ ./impact master optimize-silent-fails
Measuring commit master... OK
Measuring commit optimize-silent-fails... OK

Speed impact
------------
Before:     152.07 kB/s
After:      173.18 kB/s
Difference: 13.88%

Size impact
-----------
Before:     721705 b
After:      646518 b
Difference: -10.42%

(Measured by /tools/impact with Node.js v0.10.18 on MINGW32_NT-6.0 1.0.18(0.48/3/2) i686.)

@Mingun Mingun force-pushed the optimize-silent-fails branch 2 times, most recently from 34d0485 to 156a6af Compare January 18, 2016 17:10
@Mingun Mingun force-pushed the optimize-silent-fails branch 2 times, most recently from f17269c to b2fd6a8 Compare September 15, 2016 17:35
@Mingun
Copy link
Contributor Author

Mingun commented Sep 18, 2016

Last measurement show, that speed impact equals 1-4% (master is 5160235, optimize-silent-fails is b2fd6a8):

$ ./impact master optimize-silent-fails
Measuring commit master... OK
Measuring commit optimize-silent-fails... OK

Speed impact
------------
Before:     544.60 kB/s
After:      556.25 kB/s
Difference: 2.13%

Size impact
-----------
Before:     669581 b
After:      641730 b
Difference: -4.16%

(Measured by /tools/impact with Node.js v4.5.0 on MINGW64_NT-6.1 2.3.0(0.291/5/3) x86_64.)

options.allowedStartRules = ast.rules.length > 0
? [ast.rules[0].name]
: [];
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for this? ast.rules.length is always 1 or more, and the default value for options.allowedStartRules is [ast.rules[0].name], so there shouldn't be a need for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ast.rules.length is always 1 or more

parse contract not guarantee it. Grammar without any rules still valid and can be occured in tests. The same reason for which all this if block in general exists -- tests are the special code demanding the special relation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean the parse contract doesn't guarantee it? The parser currently generated from the grammar will throw an error when a grammar without any rules is passed to it, so it is guaranteed that there will always be one rule from the PEG.js parser.

As I could not find a test case that ensured empty grammars are not accepted by the parser, I added one on my development-overhaul branch.

As for the compiler option allowedStartRules, since there will always be at least 1 rule, you can always expect it to be set as the compiler option default for allowedStartRules, so there's no need to set this, even in the test's, unless you are intentionally passing a rule name that doesn't exist to ensure the compiler throws an error.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The parser currently generated from the grammar will throw an error when a grammar without any rules is passed to it

This is implementation detail. There are no reasonable reasons to do it. And if it changes in the future, tests which do not depend on it shall not fall. To test in the assumption as the code works means that you have no tests.

so there's no need to set this, even in the test's,

As it is possible to see few lines above, the options can be not supplied to the test and then it is meant empty. Thus, malformed data which to it shall not be supplied are obviously supplied to pass. Whether means it that the test in principle is totally wrong because it tries to expect correct behavior from a code, supply it certainly malformed data?

From this point of view this code only adds reasonable defaults to a test code, without forcing the developer of tests to supply their every time. Such simplification of operation is also required from the utility method, you do not agree?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since I do plan to add module support (#523) and annotations, it is likely in the future that there will be grammar files without rules, and you are correct that having this in the helper could actually be a plus for any developers making tests, so I accept this change, but can you extract this into a separate PR as this is a separate issue from this PR.

While you're at it, could you also in this new PR remove the related if ( options.allowedStartRules ) in lib/compiler/passes/report-undefined-rules.js#L22

If you don't want to make the new PR, just tell me and remove this code snippet from this PR, then I'll do the new PR at a later date.

@Mingun
Copy link
Contributor Author

Mingun commented Oct 28, 2017

OK, now changes in the test helper method done in the #541 and this rebased on top of that. I also rewrote some parts (bugfix for not handling group node, (re)writed some comments) for bigger clarity.

// Determines if rule always used in disabled report failure context,
// that means, that any failures, reported within it, are never will be
// visible, so the no need to report it.
function calcReportFailuresForRules(ast, allowedStartRules) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This pass is not extracted in the separate file because it strongly influences generation of a bytecode, and therefore shall be tested together with generation of a bytecode. Actually, it is just a detail of implementation of the bytecode generator

18, 0, 2, 2, 22, 0, 23, 1 // <expression>
]));
});

it("defines correct constants", function() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is added because I noticed, that for group node I forgot to update my PR for it, but tests did not tell me about that.

@Mingun Mingun force-pushed the optimize-silent-fails branch 2 times, most recently from cc04fda to bf82874 Compare December 19, 2017 19:10
@coveralls
Copy link

coveralls commented Dec 19, 2017

Coverage Status

Coverage increased (+1.4%) to 79.065% when pulling bf82874 on Mingun:optimize-silent-fails into a02f809 on pegjs:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage increased (+1.4%) to 79.065% when pulling bf82874 on Mingun:optimize-silent-fails into a02f809 on pegjs:master.

@futagoza
Copy link
Member

ready to merge?

@Mingun
Copy link
Contributor Author

Mingun commented Dec 20, 2017

Wait some time. I prepare the next PR with attempt to partially fix #194. It seems, it clashes with these changes

@Mingun
Copy link
Contributor Author

Mingun commented Jan 1, 2018

Now it is ready to merge

@coveralls
Copy link

coveralls commented Jan 1, 2018

Coverage Status

Coverage increased (+0.3%) to 75.583% when pulling ee47279 on Mingun:optimize-silent-fails into a7a0a0d on pegjs:master.

@futagoza futagoza merged commit 42ec335 into pegjs:master Jan 1, 2018
@Mingun Mingun deleted the optimize-silent-fails branch January 1, 2018 19:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants