Using var in limited contexts to avoid runtime TDZ checks

[DanielRosenwasser]

This issue aims to explain and track some optimization work within the TypeScript compiler and language service.

As of TypeScript 5.0, the project's output target was switched from es5 to es2018 as part of a transition to ECMAScript modules. This meant that TypeScript could rely on the emit for native (and often more-succinct) syntax supported between ES2015 and ES2018. One might expect that this would unconditionally make things faster, but surprise we encountered was a slowdown from using let and const natively!

Why is this? It's because let and const both really provide two features:

• reasonable scoping rules - let/const do not leak beyond the enclosing block scope.
• definite-declaration-checks - you cannot access a let/const variable prior to their declarations being evaluated

What's that second point look like?

function f() {
    x;
    let x = 10;
    return x;
}

Referring to x before let x = 10 has run is supposed to be an error. The idea is that x really shouldn't exist as far as anyone knows until its declaration ran. In a sense, this is just enforcing something similar in spirit to the first point around scoping rules - these let and const bindings can't be referenced until the runtime runs them; but it's enforced in a different way. The binding does sort of exist, but it's specifically an error to access it.

Why is this so subtle? The previous example is "obvious" - x is clearly used before it's declared. It happens earlier in the function than the declaration.

It's because we can capture and use these variables in functions. For example.

function f() {
    let result = g();
    let x = 10;
    return result;

    function g() {
        return x;
    }
}

Here, x ends up being accessed before it's declared when we called g() - even though g was declared after x.

This period while a binding exists but can't be accessed is often called the "temporal dead zone" (or TDZ for short). So JavaScript runtimes need to track whether they've actually hit this declaration point, and this does impose a run time cost. Often, implementations can perform optimizations and remove these checks, but it can be tough, and there are limitations.

@jakebailey recently sent out a pull request (#52656) to experiment transforming only let and const to var by using a single Babel transformation. This does lose the TDZ checks, but we developed TypeScript like this for years without too many issues. We found some significant savings - close to 8% of time reduced on some of our benchmarks. But we've been resistant to adding another build step.

Given that the parser saw the biggest savings, and that many of the hard-to-eliminate TDZ checks for engines are for closure-captured variables, I sent a recent change (#52832) to swap a slew of shared state in our parser to simple use var. Given that these variables are always initialized before calling the "work-horse" functions that act on them, it seemed like a reasonable compromise with very little loss in "code cleanliness".

The savings here appear to be very close to those of those of the #52656! So for many functions in TypeScript, our strategy is to leverage var for top-level shared variables. So far, we've performed this optimization for the following components:

• Parser: Switch let/const to var in the scanner & parser for top-levelish variables. #52832 (often 10-13% saved)
• Binder: Switch to var in binder for top level variables #52903 (often 1-3% saved)
• Checker: Swap closure state in the type-checker to var to avoid TDZ checks. #52835 (often 3-5% saved)
• Emitter/Printer/Writer: Switch to var in emitter, writer, printer #52906 (often 1.5-3% saved)

These have all seen improvements thanks to the elimination of TDZ checks! So we may continue to find other parts of the compiler that might benefit from these transformations, but at the moment we would like to limit our scope a bit.

When performing these transformations, we should leave a comment and link directly to this issue as an explainer to answer:

• Why is this code different?
• Why are we disabling our lint rules?
• Why is this more efficient?

Now long term, there are some possible improvements that the engines can apply. For example, V8 is currently tracking the issue here. In the future we may be able to swap back to the block-scoped declarations, but we'll probably want to delay that move until enough people are on these newer engines so they can easily benefit.

We also don't necessarily believe that all code should automatically jump to using var instead. We found a compromise based on well-understood tradeoffs for our codebase. We would recommend anyone else apply sound judgment and profiling/performance tests before performing broad refactorings like this.

[fatcerberus]

inb4 node announces a switch to jsc which doesn't have this problem thus rendering the whole point moot (not that I think this will actually happen, but it would be amusing 😄)

[jakebailey]

Truthfully, I'm not sure whether the reason JSC doesn't suffer from this problem is because it actually has optimized it better, or if their var is just as slow as their let/const.

(To be clear, this is not a dig at JSC; I honestly don't know how it works or how it compares to v8 outside the limited benchmarks related to this issue.)

[fatcerberus]

On a more serious note, I'm personally leery of this change because the decision is based purely on implementation details of V8 that make let/const slower than var, which might not always be true. But I do understand the performance is important and to be fair it seems extremely unlikely that V8's var would ever become slower than let/const so probably a safe change. Still makes me uncomfortable.

[RyanCavanaugh]

the decision is based purely on implementation details of V8

I'm trying to think of a situation where that's not the case and not coming up with much. There are a lot of micro-optimizations that depend on the runtime's behavior; it really can't be avoided. The ES spec doesn't specify which things are slow and which are fast.

[fatcerberus]

I guess I just prefer to stick to more high-level optimizations in my own code, like replacing a bubblesort with a quicksort, that sort of thing. Although I guess let -> var kind of falls under that umbrella if you squint a little, since the specified behavior is indeed simpler (i.e. no TDZ tracking)¹.

Footnotes

1. The main thing I try to avoid is doing an awkward thing today because it's faster, only to find out tomorrow that the implementation has changed and now it's slower, thus incurring a bunch of technical debt for no reason. ↩

[DanielRosenwasser]

I think we do too, but when 8% of your compile time is the engine doing TDZ checks, I'm not sure I could argue for implementing in a manner that intentionally ignores the runtime internals. On larger codebases, half a second is spent on these checks in the parser. And there's a lot more people using TypeScript than building it!

[DanielRosenwasser]

Also, even if this got optimized in V8 by Node 20 or some future version, we would still want to run well on previous versions of Node.js too.

[fatcerberus]

On larger codebases, half a second is spent on these checks in the parser.

If this is the case (which I'm not arguing; I believe you!), I haven't found a way to deduce that from typescript-bot's perf results, which for the most part only seem to exhibit differences in milliseconds...

[jakebailey]

On larger codebases, half a second is spent on these checks in the parser.

If this is the case (which I'm not arguing; I believe you!), I haven't found a way to deduce that from typescript-bot's perf results, which for the most part only seem to exhibit differences in milliseconds...

See #52832 (comment); Angular and state both get about 0.5s faster, just from the parser change.

[guilhermesimoes]

Downleveling to var also has a bundle size impact. var is shorter than const and if we have a mix of const and let declarations, I assume they could all be grouped with a single var declaration.