-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
benchmark: var to const #13757
benchmark: var to const #13757
Conversation
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.
I don't have a strong opinion on this if someone can confirm that there is no performance degression.
benchmark/process/next-tick-depth.js
Outdated
@@ -1,6 +1,7 @@ | |||
'use strict'; | |||
var common = require('../common.js'); | |||
var bench = common.createBenchmark(main, { | |||
|
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.
Any particular reason why you introduced a LF here but not in other files?
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.
It stumbled over it while I cherry-picked this part from the other PR due to a conflict in this file. I can keep it as it is if you want me to undo it.
Historically, we have held off updating the code in benchmarks so that we can more realistically compare performance with older Node.js versions. We should be careful making these kinds of changes. @mscdex ... thoughts? |
I don't have any opinion, we currently have mixed |
Is there any conclusion about how to further progress? I guess as the benchmarks already contain const, this is a safe thing? Note: the benchmarks change fast and I did this change by having a own eslint fix rule, so I would rebase as soon as there's a conclusion about how to go on. |
Just as info - I am going to update this as soon as v8 6.1 lands. I think we are safe to land this because we already use const in the benchmarks and it will only only deopt in rare cases in older v8 versions. |
I'm marking it blocked for now then. Please remove the label when you're ready to update! |
63e4520
to
c60a7cd
Compare
Rebased. This should now be possible to land since we got v8 6.1 on master. |
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
@bmeurer what do you think? |
I would like to land this soon because the code base changes fast and I have to rebase often otherwise. |
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.
Nice cleanup!
c60a7cd
to
3e0bb2d
Compare
Thanks a lot! Landed in e167ab7 |
PR-URL: #13757 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
This requires #14881 backport to land in v8.x before it can be cherry-picked |
PR-URL: nodejs#13757 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
PR-URL: #13757 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
PR-URL: nodejs/node#13757 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
PR-URL: nodejs/node#13757 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Tobias Nießen <[email protected]>
Should this be backported to This is likely to make benchmarks on 6.x slower though. TBQH I'm not sure this should have landed prior to 6.x going into maintenance mode as it will make future backports harder. That being said benchmarks have diverged quite a bit so it might be a moot point. Glad to see this was part of the conversation prior to landing. |
After looking at this again I do not really see the necessity for a backport here. If we add a new benchmark, backporting will be fine all the time. Changing benchmarks happens pretty rarely otherwise. If a backport is really necessary, I am of course fine to do so. It is not really much work as I just use a individual eslint rule for it. I am not sure anymore how bad @MylesBorins your call if I should open a backport or not. |
As discussed in #13732: this will change all
var
toconst
if applicable.The main question is if this is wanted due to the churn.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
benchmark