-
-
Notifications
You must be signed in to change notification settings - Fork 33.8k
benchmark: var to const #13757
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
Conversation
tniessen
left a comment
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
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. |
mcollina
left a comment
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. |
bmeurer
left a comment
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 <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
|
This requires #14881 backport to land in v8.x before it can be cherry-picked |
PR-URL: nodejs#13757 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
PR-URL: #13757 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
PR-URL: nodejs/node#13757 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
PR-URL: nodejs/node#13757 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>
|
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
vartoconstif 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