-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Revert "timers: refactor to use optional chaining" #38245
Conversation
This reverts commit d8f535b.
Should we report this towards v8? |
Yea this seems like a V8 issue. @nodejs/v8 |
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.
LGTM, gj
cc @nodejs/tsc |
I wanted to prove it with a benchmark and open a V8 issue but it seems optional chaining is mostly faster (at least with V8 8.9): https://jsben.ch/BwkJK |
@mcollina: What node version were you trying this on? |
I have literally no clue why, but without optional chaining those function calls get inlined. Those flamegraphs come from master. |
That's a good point, thanks. I'll try to do a different benchmark to show that optional chaining prevents inlining. |
It's not that easy. Everything gets inlined with this example: 'use strict';
function getPropClassic(obj) {
return obj && obj.prop;
}
function getPropOptional(obj) {
return obj?.prop;
}
const obj = { prop: 42 };
function testGetPropClassic(obj) {
return getPropClassic(obj);
}
function testGetPropOptional(obj) {
return getPropOptional(obj);
}
for (let i = 0; i < 1e6; i++) {
testGetPropClassic(obj);
testGetPropOptional(obj);
}
|
@targos I'm curious... Can you try that example but with obj replaced with a class with a getter? class Obj { get prop() { return 42; } }
const obj = new Obj() Also, let's see what happens when you alternate calls between the argument being |
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.
LGTM
"Build from tarball / test-tarball-linux (pull_request) " keeps failing. Is that required to pass for this landing? cc @BethGriggs |
Failure is |
I hadn't appreciated before that GH actions do not rebase. fc20e83 was the fix for the failure seen here ( |
This reverts commit d8f535b. PR-URL: #38245 Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de> Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Zijian Liu <lxxyxzj@gmail.com> Reviewed-By: Beth Griggs <bgriggs@redhat.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Landed in a0261d2 |
This reverts commit d8f535b.
As part of #37937, I tracked down a regression introduced by #36767.
With optional chaining:
Without optional chanining:
This sits in the hot path for HTTP.
I will recommend caution in adopting optional chaining in other areas of the Node.js.