[HN Gopher] V8 has optimized new JavaScript language features (2...
___________________________________________________________________
V8 has optimized new JavaScript language features (2018)
Author : hbrundage
Score : 72 points
Date : 2020-11-07 17:09 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| [deleted]
| Gaelan wrote:
| This should be (2018).
| dang wrote:
| Added. Thanks!
| chrismorgan wrote:
| > _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.
| golergka wrote:
| Wouldn't "looking at the let" take some cpu time?
| jlokier wrote:
| "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.)
| rewq4321 wrote:
| 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.
| jlokier wrote:
| An interesting point, however direct "eval" is a special
| case.
|
| It's already known that functions containing direct "eval"
| are not subject to the same level of performance
| optimisations as other functions. There is no way to obscure
| the call to direct "eval" itself; the compiler knows clearly
| whether it occurs.
|
| Without "eval" appearing syntactically inside a function's
| scope, there is no dynamic access to "let" variables, and
| there's no need for the JIT code to check the assumption at
| run time.
|
| Despite no other assignments, the "let" variable does change
| value: It has the assigned value after the "let", and the
| "temporal dead zone" value before it in the same scope.
| However "const" also has this property so it's not obvious
| why there would be a speed difference.
| [deleted]
| chrisseaton wrote:
| These checks can be completely free, in terms of runtime
| cost, through deoptimisation.
| dean177 wrote:
| 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...
| chrisseaton wrote:
| Right... but the question was 'why can't the same thing be
| done with let'.
|
| The answer is probably a combination of 'they haven't gotten
| around to it yet', 'they don't see the need', 'they don't
| want the complexity', and 'they don't want to spend compile
| time doing that.'
| franciscop wrote:
| Because you cannot know whether the let variable is
| changing just with static analysis without running the
| associated code, right?
| lenz2020 wrote:
| In strict mode you can because you can statically
| determine if eval is present. If it isn't, it is trivial
| to determine if it is written to after initialization.
|
| Otherwise it has the same issues as const (is there a
| temporal dead zone violation?)
| chrismorgan wrote:
| I think you may have misread my comment?
| grapehut wrote:
| 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.
| talolard wrote:
| Buried in there is that we finally get named capture groups on
| regular expressions. What a day!
| [deleted]
| js2 wrote:
| 2018, so it's been a couple years.
| saurik wrote:
| In stark contrast: "Using const/let instead of var can make
| JavaScript code run 10x slower in Webkit" ;P.
|
| https://news.ycombinator.com/item?id=24844353
| inbx0 wrote:
| I know you jest, but I don't think that's a good example of
| "contrast" between the engines. That was just a bug/oversight
| and fixed in a couple of weeks after it was reported [1].
|
| [1]: https://trac.webkit.org/changeset/269115/webkit
| markdog12 wrote:
| Actually, it was reported about a year ago by the Dart team:
| https://bugs.webkit.org/show_bug.cgi?id=199866.
|
| It was an excellent bug report, complete with a reproducible
| example.
|
| Only after it recently made the rounds on Twitter and hn was
| it fixed.
|
| https://mobile.twitter.com/mraleph/status/132175888792258969.
| ..
___________________________________________________________________
(page generated 2020-11-07 23:01 UTC)