-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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 -> const before merging mass rewrites #8637
Comments
Most of the mass rewrite is in tests. This only really needs to apply to |
Probably. I wouldn't mind the tests running faster either but I doubt it would be noticeable. |
Btw, I’m sorry if you feel like this is all a bit much. There were a lot more people showing up than anyone anticipated, so distributing tasks was kind of an ad-hoc thing, and I think most of us see that as a really positive thing (the big turnout) – @Fishrock123 @mscdex @cjihrig @targos and everyone else who’s not busy here and reviewing: you are just the best. ❤️ |
Yes, my primary concern was about code in lib/. I will try to do some benchmarking this weekend and also see what the story is with V8 5.4. |
I've checked 'use strict'
var suite = new require('benchmark').Suite()
suite.add('const', function () {
const value = 2
var result = 1
for (var i = 0; i < 10000; i++) {
result += value
}
})
suite.add('var', function () {
var value = 2
var result = 1
for (var i = 0; i < 10000; i++) {
result += value
}
})
suite.add('let+const', function () {
const value = 2
let result = 1
for (let i = 0; i < 10000; i++) {
result += value
}
})
suite.on('cycle', cycle)
suite.run()
function cycle (e) {
console.log(e.target.toString())
} v6.6.0:
v4.5.0:
I would say using |
I'm not so sure it's quite that easy to benchmark as there could be many factors (e.g. assigning a constant value vs a function call return value, function (de)optimizations, etc.). |
Do we have a reason to expect different (better) benchmark result with V8 5.4? |
I would suggest the following rule of thumb, until TurboFan becomes the default optimizer (sometime next year):
EDIT: but measure first. In most cases it doesn't matter. Be wary of making generalizations based on micro-benchmarks. |
I'd like to point out that by keeping benchmarks using the absolute latest features it makes it impossible to test them against older versions of Node. Requiring editing the file and removing the offending syntax. I'd say for benchmarks that don't involve new JS features we use the backwards compatible syntax as much as possible. |
Yeah, 100% what @trevnorris said where possible. |
Motivation: Currently the guidelines put this into the "linting won't catch this" section, because we've just been using plain semistandard. Modification: * Add prefer-const rule, which will force usage of const if an identifier is never reassigned. More info: http://eslint.org/docs/rules/prefer-const * Add no-use-before-define rule, which will prevent ReferenceErrors being thrown due to "temporal dead zone" issues with const/let. More info: http://eslint.org/docs/rules/no-use-before-define * Add block-scoped-var rule, which will force var to act like let. The current guidelines recommend against using var, and instead using let for mutable variables. Unfortunately, let currently doesn't perform as well as const or var: nodejs/node#8637 (comment) More info on this rule: http://eslint.org/docs/rules/block-scoped-var * Remove the recommendation to check for this manually.
Let/const performance in V8 was recently improved: #9729 (comment) |
@nodejs/collaborators
Suggested by @mscdex in #8609 (comment)
The text was updated successfully, but these errors were encountered: