V8 has optimized new JavaScript language features (2018)
1–10 of 53 posts
Re: V8 has optimized new JavaScript language features (2018)
#2Buried in there is that we finally get named capture groups on regular expressions. What a day!
Re: V8 has optimized new JavaScript language features (2018)
#3This should be (2018).
Re: V8 has optimized new JavaScript language features (2018)
#4> const performs a lot better in optimized code than var or let
This puzzles me; if only ever one value is assigned, I would have expected at least let to perform identically to const in optimised code, because I expect the optimiser to look at the let and say “never reassigned, turn it into a const”. By the sound of it, I’m wrong, and I’d be interested to know why I’m wrong.
Re: V8 has optimized new JavaScript language features (2018)
#5> const performs a lot better in optimized code than var or let This puzzles me; if only ever one value is assigned, I would have expected at least let to perform identically to const in optimised code, because I expect the optimiser to look at the let and say “never reassigned, turn it into a const ”. By the sound of it, I’m wrong, and I’d be interested to know why I’m wrong.
Wouldn't "looking at the let" take some cpu time?
Re: V8 has optimized new JavaScript language features (2018)
#6> const performs a lot better in optimized code than var or let This puzzles me; if only ever one value is assigned, I would have expected at least let to perform identically to const in optimised code, because I expect the optimiser to look at the let and say “never reassigned, turn it into a const ”. By the sound of it, I’m wrong, and I’d be interested to know why I’m wrong.
JavaScript is very dynamic. Here I define a variable with `let` and then change it:
let foo = 10; eval("fo"+"o = 10");
I could "obfuscate" that eval assignment as much as I like. So you can't completely statically analyse `let` variables.
That said, it's likely you'd end up with perf very close to `const` in a very "hot" part of your code, since a good JIT compiler like V8 will eventually make "assumptions" about your code, and optimise around them, while having (ideally cheap) checks in place to ensure the assumptions continue to hold.
Re: V8 has optimized new JavaScript language features (2018)
#7> const performs a lot better in optimized code than var or let This puzzles me; if only ever one value is assigned, I would have expected at least let to perform identically to const in optimised code, because I expect the optimiser to look at the let and say “never reassigned, turn it into a const ”. By the sound of it, I’m wrong, and I’d be interested to know why I’m wrong.
The const keyword also guarantees that once a value is assigned to its slot it won't change in the future.
As a result TurboFan skips loading and checking const slot values slots each time they are accessed (Function Context Specialization)
https://github.com/thlorenz/v8-perf/blob/master/language-fea...
Re: V8 has optimized new JavaScript language features (2018)
#8> const performs a lot better in optimized code than var or let This puzzles me; if only ever one value is assigned, I would have expected at least let to perform identically to const in optimised code, because I expect the optimiser to look at the let and say “never reassigned, turn it into a const ”. By the sound of it, I’m wrong, and I’d be interested to know why I’m wrong.
Because such analysis isn't free, especially when it's just in time. In theory it could and maybe will in the future, but it's hard to do every possible analysis and optimization.
Re: V8 has optimized new JavaScript language features (2018)
#9> const performs a lot better in optimized code than var or let This puzzles me; if only ever one value is assigned, I would have expected at least let to perform identically to const in optimised code, because I expect the optimiser to look at the let and say “never reassigned, turn it into a const ”. By the sound of it, I’m wrong, and I’d be interested to know why I’m wrong.
Wouldn't "looking at the let" take some cpu time?
"Looking at the let" refers to code analysis during JIT compile time, which happens once for each bit of code, not run time which happens many times as the same bits of code are run.
When comparing the speed of "const" versus "let", the JIT compile time is irrelevant; the speed differences being looked at are entirely run time, inside loops.
Also the JIT compile time difference from "looking at the let" will be so low as to be virtually unmeasurable anyway. (It is such a trivial check, much simpler than almost everything else the compiler does.)
(However, see rewq4321's sibling comment about analysability and JavaScript being a very dynamic language when "eval" is used.)
Re: V8 has optimized new JavaScript language features (2018)
#10> const performs a lot better in optimized code than var or let This puzzles me; if only ever one value is assigned, I would have expected at least let to perform identically to const in optimised code, because I expect the optimiser to look at the let and say “never reassigned, turn it into a const ”. By the sound of it, I’m wrong, and I’d be interested to know why I’m wrong.
JavaScript is very dynamic. Here I define a variable with `let` and then change it: let foo = 10; eval("fo"+"o = 10"); I could "obfuscate" that eval assignment as much as I like. So you can't completely statically analyse `let` variables. That said, it's likely you'd end up with perf very close to `const` in a very "hot" part of your code, since a good JIT compiler like V8 will eventually make "assumptions" about you…
These checks can be completely free, in terms of runtime cost, through deoptimisation.