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

Benchmark var -> const before merging mass rewrites #8637

Closed
Fishrock123 opened this issue Sep 17, 2016 · 11 comments · May be fixed by adamlaska/node#38
Closed

Benchmark var -> const before merging mass rewrites #8637

Fishrock123 opened this issue Sep 17, 2016 · 11 comments · May be fixed by adamlaska/node#38
Labels
meta Issues and PRs related to the general management of the project. performance Issues and PRs related to the performance of Node.js. v8 engine Issues and PRs related to the V8 dependency.

Comments

@Fishrock123
Copy link
Contributor

Fishrock123 commented Sep 17, 2016

@nodejs/collaborators

Suggested by @mscdex in #8609 (comment)

This may sound a bit crazy, but we may want to benchmark this change. I noticed not too long ago that var => const was actually causing slowdowns and timers are definitely a hot path. I do not know if this has changed with V8 5.4 or not though.

@Fishrock123 Fishrock123 added v8 engine Issues and PRs related to the V8 dependency. meta Issues and PRs related to the general management of the project. performance Issues and PRs related to the performance of Node.js. labels Sep 17, 2016
@cjihrig
Copy link
Contributor

cjihrig commented Sep 17, 2016

Most of the mass rewrite is in tests. This only really needs to apply to lib/ code right?

@Fishrock123
Copy link
Contributor Author

Fishrock123 commented Sep 17, 2016

Probably. I wouldn't mind the tests running faster either but I doubt it would be noticeable.

@addaleax
Copy link
Member

addaleax commented Sep 17, 2016

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. ❤️ </offtopic>

@mscdex
Copy link
Contributor

mscdex commented Sep 17, 2016

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.

@mcollina
Copy link
Member

I've checked const vs var vs let in node v4 and v6 with the following script:

'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:

const x 156,967 ops/sec ±0.63% (90 runs sampled)
var x 156,124 ops/sec ±0.77% (88 runs sampled)
let+const x 34,882 ops/sec ±0.76% (91 runs sampled)

v4.5.0:

const x 157,721 ops/sec ±0.80% (86 runs sampled)
var x 159,177 ops/sec ±0.74% (91 runs sampled)
let+const x 9,881 ops/sec ±0.92% (87 runs sampled)

I would say using const is safe, using let should be highly discouraged.

@mscdex
Copy link
Contributor

mscdex commented Sep 21, 2016

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.).

@imyller
Copy link
Member

imyller commented Sep 21, 2016

Do we have a reason to expect different (better) benchmark result with V8 5.4?

@ofrobots
Copy link
Contributor

ofrobots commented Sep 21, 2016

I would suggest the following rule of thumb, until TurboFan becomes the default optimizer (sometime next year):

  • Avoid let for variables that are modified inside loops. When in doubt, stick with var.

EDIT: but measure first. In most cases it doesn't matter. Be wary of making generalizations based on micro-benchmarks.

@trevnorris
Copy link
Contributor

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.

@Fishrock123
Copy link
Contributor Author

Yeah, 100% what @trevnorris said where possible.

@AndreasMadsen AndreasMadsen mentioned this issue Oct 14, 2016
2 tasks
grdryn added a commit to grdryn/entente that referenced this issue Nov 12, 2016
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.
@fhinkel
Copy link
Member

fhinkel commented Dec 14, 2016

Let/const performance in V8 was recently improved: #9729 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Issues and PRs related to the general management of the project. performance Issues and PRs related to the performance of Node.js. v8 engine Issues and PRs related to the V8 dependency.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants