5 ms·

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

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-features.md#const https://github.com/thlorenz/v8-perf/blob/master/language-fea...

chrismorgan 6y ago
I think you may have misread my comment?
chrisseaton 6y ago
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 6y ago
  Because you cannot know whether the let variable is changing just with static analysis without running the associated code, right?
  - lenz2020 6y ago
    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?)
  - chrisseaton 6y ago
    > 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.
    - klodolph 6y ago
      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.
      - chrisseaton 6y ago
        > What speculation? Speculating that a debugger is not attached and modifying local variables, is one example. > in the common case it should (at least) be something you could do just by walking the AST Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases.
        Dylan16807 6y ago
        > Speculating that a debugger is not attached and modifying local variables, is one example. A debugger can do anything. You can't outthink a debugger and shouldn't try. > Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases. Speculation is when you guess and need to have a guard in case the guess is wrong. They're describing a situation where it can't be wrong and you wouldn't need to speculate.
        chrisseaton 6y ago
        > A debugger can do anything. You can't outthink a debugger Yes that's what we're saying. So you deoptimise when someone starts debugging. > and shouldn't try You'd get extremely slow code with this approach! > Speculation is when you guess and need to have a guard in case the guess is wrong. Yes, you're guessing that nobody will attach a debugger and you're guarding that no debugger has been attached. That guard is usually implicit. > They're describing a situation where it can't be wrong and you wouldn't need to speculate. It can be wrong... if someone's using a debugger. So you need to speculate that they aren't using a debugger. I wrote a PhD about using speculation and deoptimisation to solve the problem of people debugging optimised code.
- ConcernedCoder 6y ago
  The question needs to be "why on earth would you want to do that with let, when you should just make it a const?"
  - klodolph 6y ago
    Because minifiers can shave a few bytes by converting a mixture of const/let to use just let.

chrismorgan 6y ago

I think you may have misread my comment?

chrisseaton 6y ago

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 6y ago
Because you cannot know whether the let variable is changing just with static analysis without running the associated code, right?
- lenz2020 6y ago
  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?)
- chrisseaton 6y ago
  > 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.
  - klodolph 6y ago
    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.
    - chrisseaton 6y ago
      > What speculation? Speculating that a debugger is not attached and modifying local variables, is one example. > in the common case it should (at least) be something you could do just by walking the AST Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases.
      - Dylan16807 6y ago
        > Speculating that a debugger is not attached and modifying local variables, is one example. A debugger can do anything. You can't outthink a debugger and shouldn't try. > Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases. Speculation is when you guess and need to have a guard in case the guess is wrong. They're describing a situation where it can't be wrong and you wouldn't need to speculate.
        chrisseaton 6y ago
        > A debugger can do anything. You can't outthink a debugger Yes that's what we're saying. So you deoptimise when someone starts debugging. > and shouldn't try You'd get extremely slow code with this approach! > Speculation is when you guess and need to have a guard in case the guess is wrong. Yes, you're guessing that nobody will attach a debugger and you're guarding that no debugger has been attached. That guard is usually implicit. > They're describing a situation where it can't be wrong and you wouldn't need to speculate. It can be wrong... if someone's using a debugger. So you need to speculate that they aren't using a debugger. I wrote a PhD about using speculation and deoptimisation to solve the problem of people debugging optimised code.
ConcernedCoder 6y ago
The question needs to be "why on earth would you want to do that with let, when you should just make it a const?"
- klodolph 6y ago
  Because minifiers can shave a few bytes by converting a mixture of const/let to use just let.