Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

V8 has optimized new JavaScript language features (2018)

github.com

Post reply on HN
Print view View original

21–30 of 53 posts

Re: V8 has optimized new JavaScript language features (2018)

#21

Post by franciscop »

chrisseaton wrote: post #18
dean177 wrote: post #7

Earlier quoted context omitted.

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

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

Because you cannot know whether the let variable is changing just with static analysis without running the associated code, right?

Re: V8 has optimized new JavaScript language features (2018)

#22

Post by markdog12 »

inbx0 wrote: post #20
saurik wrote: post #19

In stark contrast: "Using const/let instead of var can make JavaScript code run 10× slower in Webkit" ;P. https://news.ycombinator.com/item?id=24844353

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

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

Re: V8 has optimized new JavaScript language features (2018)

#23

Post by lenz2020 »

franciscop wrote: post #21
chrisseaton wrote: post #18

Earlier quoted context omitted.

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

Because you cannot know whether the let variable is changing just with static analysis without running the associated code, right?

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

Re: V8 has optimized new JavaScript language features (2018)

#24

Post by chrisseaton »

franciscop wrote: post #21
chrisseaton wrote: post #18

Earlier quoted context omitted.

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

Because you cannot know whether the let variable is changing just with static analysis without running the associated code, right?

> just with static analysis

You're not doing static analysis - you're doing dynamic analysis and speculation. But this has the downsides I said - it's more complicated, it takes more time, etc.

Re: V8 has optimized new JavaScript language features (2018)

#25

Post by syrrim »

jlokier wrote: post #12
rewq4321 wrote: post #6

Earlier quoted context omitted.

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…

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" variab…

> There is no way to obscure the call to direct "eval" itself;

Jsfuck would like to have a word with you

Re: V8 has optimized new JavaScript language features (2018)

#26

Post by kjeetgill »

jlokier wrote: post #9
golergka wrote: post #5

Earlier quoted context omitted.

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 lo…

FYI - you're probably getting downvoted because JIT-time is generally considered runtime and the cost of JIT time is usually consider with end user performance in mind.

Re: V8 has optimized new JavaScript language features (2018)

#27

Post by Mavvie »

syrrim wrote: post #25
jlokier wrote: post #12

Earlier quoted context omitted.

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" variab…

> There is no way to obscure the call to direct "eval" itself; Jsfuck would like to have a word with you

Doesn't JSFuck only work when strict mode is off?

Re: V8 has optimized new JavaScript language features (2018)

#28

Post by ithkuil »

syrrim wrote: post #25
jlokier wrote: post #12

Earlier quoted context omitted.

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" variab…

> There is no way to obscure the call to direct "eval" itself; Jsfuck would like to have a word with you

Does it actually behave like having a literal eval in the function?

Re: V8 has optimized new JavaScript language features (2018)

#30

Post by sjrd »

dandigangi wrote: post #29

"entirely new approach to how bound function exotic objects are implemented" Does anyone have information on using the term "exotic"? I haven't heard that before and not sure how to understand what they meant by that.

It's a specific term used in the ECMAScript specification [1]. That refers to any object for which at least one internal method does not behave like for a standard object created for example with `{}`.

[1] http://www.ecma-international.org/ecma-262/

Post reply on HN