I'm pretty sure destructuring is still slow as hell. Like if you want to clone an array, arr.slice(0) is 3x faster than [...arr]
V8 has optimized new JavaScript language features (2018)
31–40 of 53 posts
Re: V8 has optimized new JavaScript language features (2018)
#32In 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
YMMV, but I find that Safari uses dramatically fewer local resources on my computer than Chrome does, for the same workload. Chrome can’t remotely handle the number of tabs I typically keep open (it chews up all available memory, and hangs or crashes). Even for lighter browsing usage, Chrome chews battery faster and slows the rest of my computer down. Overall Safari is the most usable, followed by Firefox.
In various numerical computing in Javascript projects/experiments I’ve done, Safari is typically fastest, but not always. At any rate, it is clear that all of these teams have done very extensive optimization work, and all of the modern browsers are engineering marvels.
But there are a lot of weird nooks and corners in all of the browsers when it comes to Javascript performance.
Re: V8 has optimized new JavaScript language features (2018)
#33In 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
YMMV, but I find that Safari uses dramatically fewer local resources on my computer than Chrome does, for the same workload. Chrome can’t remotely handle the number of tabs I typically keep open (it chews up all available memory, and hangs or crashes). Even for lighter browsing usage, Chrome chews battery faster and slows the rest of my computer down. Overall Safari is the most usable, followed by Firefox. In various…
As someone who uses JavaScriptCore in most of my projects (there is one for which I am currently intending to use v8, which is seriously "off brand" for me), and only finds Chrome usable with The Great Suspender (at which point I do use it instead of Safari for various reasons, particularly since I now use a Windows desktop ;P), I agree with you; but, everything you said seems unrelated to the topic?...
Re: V8 has optimized new JavaScript language features (2018)
#34Earlier quoted context omitted.
YMMV, but I find that Safari uses dramatically fewer local resources on my computer than Chrome does, for the same workload. Chrome can’t remotely handle the number of tabs I typically keep open (it chews up all available memory, and hangs or crashes). Even for lighter browsing usage, Chrome chews battery faster and slows the rest of my computer down. Overall Safari is the most usable, followed by Firefox. In various…
As someone who uses JavaScriptCore in most of my projects (there is one for which I am currently intending to use v8, which is seriously "off brand" for me), and only finds Chrome usable with The Great Suspender (at which point I do use it instead of Safari for various reasons, particularly since I now use a Windows desktop ;P), I agree with you; but, everything you said seems unrelated to the topic?...
For years people have been ragging on Safari for being slightly slower to adopt new features, usually with the implication that they are holding back the web. But I think their current priorities are just fine.
I assume all of the ES2015 features will eventually see the same level of optimization as ES5-era code. I’m not too worried if it takes a few more years.
Re: V8 has optimized new JavaScript language features (2018)
#35Earlier 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…
These checks can be completely free, in terms of runtime cost, through deoptimisation.
How? You have to do some kind of check with let, and you don't with const.
Re: V8 has optimized new JavaScript language features (2018)
#36Earlier 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
Nice try! The Jsfuck method can't encode a direct "eval", only an indirect one :-)
Thus the emphasis on direct. Well, Jsfuck can encode a direct eval inside an indirect eval, but that doesn't give it any advantages, it still can't access the surrounding lexical environment in the form of "let" and "const" variables.
(I didn't know about Jsfuck though - it looks fun, thanks!)
Re: V8 has optimized new JavaScript language features (2018)
#37Earlier quoted context omitted.
"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.
> the cost of JIT time is usually consider with end user performance in mind.
Indeed it is. I know that (very well), I guess I didn't phrase my comment well though.
The article points out that a "const" variable access is faster than a "let" variable access due to removal of certain run time checks in the JIT-generated code.
The per-statement cost of lexing, parsing, analysing, and code-generating for each statement of the JavaScript source is far, far greater than the cost of actually executing the generated code for a "const" or "let" variable access.
So much so, that if the generated variable access was run as a one-off, the speed difference would be undetectable.
So the only way for there to be an end-user visible difference in speed between "const" and "let" is in code where the JIT-code-generated variable accesses are run many times repeatedly.
The time to perform "is the 'let' variable assigned to" is part of the one-off checks, not the repeated executions. Since we're also talking about "optimised code" not "unoptimised code" from the JIT, it's also a tiny amount of time compared with most other things done by the optimiser. It is literally a boolean flag, false by default, set true if any assignment to the variable is seen when parsing or optimising. And "optimised code" is only produced for code that is run many times.
So technically, yes, the check would technically take end user-visible time. But only in situations where there is another end user-visible time which dominates over it (the slowdown of "let" versus "const" variable accesses done repeatedly), and which the check is intended to remove. Thus you could say, the check's time would be cancelled out.
(It's a little bit like comparing the O(1) parts of an algorithm with the O(N) parts, when you have been told that N is significant. If you can do something to reduce the O(N) constant factors and it costs O(1) to do, it's a net speedup for sufficiently large N.)
Re: V8 has optimized new JavaScript language features (2018)
#38Earlier 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.'
The question needs to be "why on earth would you want to do that with let, when you should just make it a const?"
Re: V8 has optimized new JavaScript language features (2018)
#39Earlier 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.'
The question needs to be "why on earth would you want to do that with let, when you should just make it a const?"
Because minifiers can shave a few bytes by converting a mixture of const/let to use just let.
Re: V8 has optimized new JavaScript language features (2018)
#40Earlier quoted context omitted.
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.
What speculation? If you have a "let" in some lexical scope, AND this is strict mode, AND there are no calls to eval in that scope, AND there are no assignments within that scope... how is that different from const?
I can understand why in a JavaScript engine there may be plenty of other concerns and it may be completely reasonable to not do the analysis, but in the common case it should (at least) be something you could do just by walking the AST, if you so desired, without even knowing the surrounding code.