4 ms·
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 "
by cosmosgenius 6y ago
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.
- judge2020 6y agoIf 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.
- ihuman 6y agoIf that was the reason, then shouldn't "const" be as slow as "let"?
- kjksf 6y agoIt 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).
- charliesome 6y agoWhile 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.
- chrismorgan 6y agoThat would apply to a pure interpreter, but all JS runtimes will do at least some optimisations, even on their baseline profile.
- cosmosgenius 6y agolet wasn't inside the loop, which is what made it weird.
- akmittal 6y agonode 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
- yetanotherme 6y agoyou're not measuring what you think you are