[jlokier]

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

[kjeetgill]

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.

[jlokier]

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