Hacker News Reader

Comment by cosmosgenius | Hacker News Reader

Not sure if its still valid, but i remember doing a performance testing for "hello world"*10mil in nodejs and golang around 4-5 years back. What i noticed was "var" and "const" gave comparable results to golang, but "let" was around 100x slower for no reason. It was just a single variable declaration with "print" statement called multiple times.

View on HN

If it was written like

  while true {
    let hello = "world";
  }

The scope would keep getting freed then re-allocated, which will be slower than simply continuously setting an existing variable's memory location over and over again.

If that was the reason, then shouldn't "const" be as slow as "let"?

It should be valid to move `const` outside of the loop, since by definition it cannot be changed.

`let` can be changed so cannot be optimized out this way (at least not without doing more complex analysis and proving that the variable is not being changed).

While the creation and destruction of a scope every loop iteration is the correct mental model for what this code does, there's no reason that implementations must actually perform any allocations - especially for an example like this where it is trivially determinable that no bindings escape the immediate scope.

That would apply to a pure interpreter, but all JS runtimes will do at least some optimisations, even on their baseline profile.

let wasn't inside the loop, which is what made it weird.

node const.js 6.58s user 1.25s system 60% cpu 13.007 total

node let.js 7.00s user 1.35s system 51% cpu 16.272 total

node var.js 7.21s user 1.22s system 55% cpu 15.183 total

go run main.go 0.80s user 0.94s system 17% cpu 10.064 total

you're not measuring what you think you are

Reply on news.ycombinator.com