Navigation Menu

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

assert: improve error check #17574

Closed
wants to merge 1 commit into from
Closed

Conversation

BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Dec 9, 2017

With newer V8 versions instanceof checks became very fast and
we do not have to check for the property existence anymore.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

assert

@nodejs-github-bot nodejs-github-bot added the errors Issues and PRs related to JavaScript errors originated in Node.js core. label Dec 9, 2017
Copy link
Member

@apapirovski apapirovski left a comment

Choose a reason for hiding this comment

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

Maybe add labels re: not landing on v6.x/v8.x as appropriate. Maybe even v9.x depending on when the optimizations in V8 occurred.

@@ -140,9 +140,9 @@ class AssertionError extends Error {
if (message) {
super(message);
} else {
if (actual && actual.stack && actual instanceof Error)
Copy link
Member

Choose a reason for hiding this comment

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

This wasn't a performance microoptimization, but rather an integrity check to avoid Object.create(Error.prototype) from being recognized as an Error.

Copy link
Member

Choose a reason for hiding this comment

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

It was definitely a micro-optimization, see #15025 (and @BridgeAR introduced it). It's possible it has other side-effects although I'm not convinced Object.create(Error.prototype) is something we should worry about in this particular code.

Copy link
Member Author

Choose a reason for hiding this comment

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

I indeed did not think about this case. I also do not mind if it stays as it will not hurt.

Copy link
Member Author

Choose a reason for hiding this comment

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

@TimothyGu would you like to keep it to be on the safe side about this or shall I just remove the part again?

Copy link
Member

Choose a reason for hiding this comment

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

@apapirovski Thanks for digging up the original PR. It was very informative. @BridgeAR Feel free to remove.

@lpinca
Copy link
Member

lpinca commented Dec 11, 2017

On Node.js 9.2.1 istanceof is still slow, when was it optimized?

@apapirovski
Copy link
Member

This shouldn't land on v9.x unless V8 6.3 makes its way there.

CI: https://ci.nodejs.org/job/node-test-pull-request/12062/

@apapirovski
Copy link
Member

apapirovski commented Dec 14, 2017

Hmm, does anyone have a relevant benchmark for this? Doing some quick testing in repl indicates this might potentially be OK even on 8.x... cc @lpinca @BridgeAR

@lpinca
Copy link
Member

lpinca commented Dec 14, 2017

@apapirovski I compared instanceof Error and err.stack using https://benchmarkjs.com/ before writing that comment above and it was a lot slower.

@apapirovski
Copy link
Member

apapirovski commented Dec 14, 2017

@lpinca Right, that makes sense. I assume @BridgeAR was talking about instanceof not being prohibitively slow anymore rather than faster or as fast than the check above. It seems comparable to typeof now whereas it used to be much slower.

If this lands, it can probably land on both v8.x & v9.x because there doesn't seem to be a perf difference.

@lpinca
Copy link
Member

lpinca commented Dec 14, 2017

I didn't test it but I assume current code is still faster when an error is passed. @apapirovski do you have some numbers at hand?

@apapirovski
Copy link
Member

I didn't test it but I assume current code is still faster when an error is passed. @apapirovski do you have some numbers at hand?

I would guess that it definitely is. The question is (probably) whether we want to keep around this type of code or clean it up. I would guess that instanceof is not going to be a bottleneck here.

@lpinca
Copy link
Member

lpinca commented Dec 14, 2017

It makes sense. Reading the discussion in https://github.com/nodejs/node/pull/15025/files it shouldn't probably have been added in the first place.

@BridgeAR
Copy link
Member Author

@apapirovski
Right, that makes sense. I assume @BridgeAR was talking about instanceof not being prohibitively slow anymore rather than faster or as fast than the check above. It seems comparable to typeof now whereas it used to be much slower.

That is correct. instanceof got relatively fast in general since Turbofan landed. I do not remember exactly when. I just stumbled upon this part and did not like it very much. After running some benchmarks I actually decided to take a different way though and optimize it properly. The new code should be faster in all cases and it is also faster in the general case compared to instanceof.

@BridgeAR
Copy link
Member Author

Ping @lpinca @apapirovski @TimothyGu @jasnell @maclover7 what do you think?

@lpinca
Copy link
Member

lpinca commented Dec 19, 2017

Seems good to me, but the in operator wasn't very fast, not sure if it is now.

@lpinca
Copy link
Member

lpinca commented Dec 19, 2017

FWIW according to https://v8project.blogspot.it/2017/12/v8-release-64.html the instanceof operator is 3.6 times faster on V8 6.4

@BridgeAR
Copy link
Member Author

@lpinca that was the change that reminded me about it (https://chromium.googlesource.com/v8/v8.git/+/bcee140617fe90e8c354394216225615b9558113). I am going to check if this specific case is actually better with instanceof after 6.4 landed or if in is still faster. When I ran my benchmarks the current implementation was still better than other options.

@BridgeAR BridgeAR added dont-land-on-v6.x and removed blocked PRs that are blocked by other issues or PRs. dont-land-on-v6.x labels Feb 17, 2018
@BridgeAR
Copy link
Member Author

So I just checked this again and the current solution is still faster on master. It is also faster on v.8 and v.9 but not on v.6.

The performance divers depending on the input. But this is always faster than the current implementation.

@BridgeAR
Copy link
Member Author

@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 17, 2018
@BridgeAR BridgeAR changed the title assert: remove obsolete micro-optimization assert: improve error check Feb 17, 2018
@BridgeAR
Copy link
Member Author

The commit message should be changed before this lands.

@BridgeAR
Copy link
Member Author

Minor performance improvement.
@BridgeAR
Copy link
Member Author

BridgeAR commented Mar 2, 2018

BridgeAR added a commit to BridgeAR/node that referenced this pull request Mar 6, 2018
Minor performance improvement.

PR-URL: nodejs#17574
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
@BridgeAR
Copy link
Member Author

BridgeAR commented Mar 6, 2018

Landed in b5825e1

@BridgeAR BridgeAR closed this Mar 6, 2018
@targos targos removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Mar 17, 2018
targos pushed a commit that referenced this pull request Mar 17, 2018
Minor performance improvement.

PR-URL: #17574
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
@targos targos mentioned this pull request Mar 18, 2018
MylesBorins pushed a commit that referenced this pull request Mar 20, 2018
Minor performance improvement.

PR-URL: #17574
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
MayaLekova pushed a commit to MayaLekova/node that referenced this pull request May 8, 2018
Minor performance improvement.

PR-URL: nodejs#17574
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
@jasnell
Copy link
Member

jasnell commented Aug 17, 2018

Should this be backported to 8.x? If so, we need a separate backport PR.

@BridgeAR BridgeAR deleted the fast-instanceof branch April 1, 2019 23:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
errors Issues and PRs related to JavaScript errors originated in Node.js core.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants