Is TypeScript 7's Native Compiler Really 10x Faster? I Ran the Numbers

Microsoft’s pitch for TypeScript 7 is simple: the compiler has been ported from TypeScript to Go, and it’s roughly 8-12x faster, ~10x on average. That’s a huge claim, and it comes with no shared methodology, no raw data, and no fixtures anyone else can run. So I built my own benchmark, 26 fixtures, three compiler versions, five timed runs each, to see how that number holds up against real, reproducible measurement.

The short answer: TypeScript 7’s native compiler is a genuine, substantial improvement, just not a flat “10x” one. How much faster depends enormously on what you feed it, and the honest answer turned out to be more interesting than either “the claim is true” or “the claim is marketing.”

Table of Contents

1. What This Benchmark Actually Is
2. Why I Didn’t Just Trust the Headline Number
3. A Tour of the Results
4. Who Should Actually Care About These Numbers
5. Run It Yourself
6. Frequently Asked Questions (FAQ)
7. Conclusion: A Number Worth Distrusting Correctly
8. References

1. What This Benchmark Actually Is

This isn’t a single number. It’s 26 fixtures split across four categories, each TypeScript compiler run five times, with the median (not the mean) reported alongside a coefficient-of-variation column so noisy results are visible instead of hidden:

• 8 small fixtures: sub-second sanity checks, dominated by process-startup cost rather than actual type-checking.
• 12 heavy synthetic fixtures: adversarial patterns purpose-built to stress the type checker: deep generic chains, huge discriminated unions, mapped-type chains, template-literal combinatorics, thousands of function overloads, and more, each tuned to run ~30 seconds on classic tsc.
• 2 “mega” capstone fixtures: combined multi-pattern tests tuned to ~60 seconds each.
• 4 real-world fixtures: genuine, unmodified open-source code, not synthetic patterns: TypeScript’s own compiler source, RxJS, Zod, TypeORM, date-fns, and Excalidraw (the one application-shaped fixture, versus the others which are libraries).

Every run is a cold, full build: no incremental caching, no watch mode. Every number ships with the raw per-run JSON behind it.

2. Why I Didn’t Just Trust the Headline Number

A vendor-published performance claim with no shared data is marketing until proven otherwise: that’s true of any vendor, not a knock on Microsoft specifically. So the project was built around a simple rule: every number gets a fixture, a raw timing file, and a command to reproduce it.

That discipline paid off in an unexpected way. Building this benchmark surfaced four real bugs, and each one got corrected in public rather than quietly patched:

• An early version measured TypeScript 7’s Node.js dispatcher process instead of the actual native binary it launches: reporting ~40MB of wrapper overhead as if it were the compiler’s real memory use.
• A tsconfig.json path-mapping option (baseUrl) that’s deprecated in TypeScript 6 and removed in TypeScript 7 silently made two versions skip most of the real type-checking work on one fixture, producing a bogus ~60x “speedup” that was actually just doing almost nothing.
• Two fixtures briefly looked slower on the native compiler. Investigating with --extendedDiagnostics traced it to Windows Defender’s real-time scanner adding unpredictable overhead to fixtures that write thousands of small output files, not a compiler regression at all.
• Even the diagnostic for that last bug had its own bug: checking whether a folder is excluded from Defender requires admin rights just to read, and the first version treated “can’t read” as “not excluded,” producing false alarms.

None of that would have surfaced from trusting a single headline multiplier. It only showed up because every number had to earn its place with reproducible evidence.

3. A Tour of the Results

Here’s where the “10x” claim gets interesting: it depends entirely on which category you look at.

Real-world code is where Microsoft’s claim comes closest to holding. Type-checking TypeScript’s own compiler source is 7.93x faster; a few fixtures land close to 8-9x. That’s a genuinely different experience if your day-to-day work is “check out a real project and run tsc.”

Adversarial type-checking stress tests tell a more modest story. Deep generics, huge discriminated unions, mapped-type chains, the patterns specifically designed to make the type checker sweat, land around 3.4x, not 10x. The best single case in the whole suite is 8.01x (thousands of function overloads); the worst is 1.74x (a single enormous file), still a real win, just not a dramatic one. Notably, every one of the 26 fixtures showed native as faster. Nothing regressed.

Memory is not uniformly better. On several fixtures, native used about as much RAM as the classic compiler, and on one it used noticeably more (6.2GB vs 5.1GB) while still finishing 3.6x faster. The clear win here is speed, not memory footprint: worth knowing if your build environment is memory-constrained.

4. Who Should Actually Care About These Numbers

The numbers matter most if:

• Your CI pipeline spends real time on tsc, and your codebase looks more like “a real application” than “a generics playground”: real-world code is where the biggest wins showed up.
• You’re evaluating whether to adopt TypeScript 7 early and want to know what to actually expect, rather than a marketing multiplier.
• You care about how a performance claim was measured, not just the number at the end.

The numbers matter less if:

• Your bottleneck is editor responsiveness or incremental rebuilds: this benchmark deliberately measures cold full builds only, and says nothing about tsserver or watch-mode performance.
• You’re on Linux or macOS: every number here is from one Windows machine. The tooling has cross-platform code paths, but they’re untested on real non-Windows hardware as of writing.
• You need statistically rigorous confidence intervals: five runs is better than the three I started with, but it’s still a modest sample size, honestly labeled with a coefficient-of-variation column rather than presented as more precise than it is.

5. Run It Yourself

The whole thing is scriptable end to end, no PowerShell required for the timed benchmark itself:

git clone https://github.com/powergr/typescript-native-compiler-benchmark.git
cd typescript-native-compiler-benchmark
npm run setup   # installs deps, downloads real-world fixture source, generates all fixtures
npm run bench   # 26 fixtures x 3 versions x 5 runs: expect 60-90 minutes

Useful flags if you don’t want the full run:

node runner.js --dry-run                 # print the planned matrix and exit
node runner.js --only=21-real --runs=1   # one fixture, one quick pass
node runner.js --json-only               # skip the markdown report, for tooling

Every fixture’s size knob lives in generators/generate-all.js with a rationale comment, so you can retune the synthetic fixtures for your own hardware rather than trusting mine.

6. Frequently Asked Questions (FAQ)

Is TypeScript 7’s native compiler actually 10x faster?

Sometimes, on real-world code. Averaged across a broader mix that includes adversarial type-checking patterns, the geometric mean in this benchmark is 3.68x. Both are true; neither is the whole story.

Why does the “vs 6.0.3” column matter, not just “vs 5.8.3”?

TypeScript 6.0.3 is itself a modest improvement over 5.8.3 (about 1.17x overall): still the classic V8-based compiler, no native port. Comparing 7.0.2 only against the older 5.8.3 baseline slightly inflates the apparent jump; the 6.0.3 comparison isolates what’s actually attributable to the native port itself.

Did you download the TypeScript compiler’s own source to test it?

Yes, a read-only snapshot archive of the tagged v5.8.3 release, alongside RxJS, Zod, TypeORM, date-fns, and Excalidraw. No forks, no modifications, no git clone, just plain HTTP downloads of public release archives, type-checked as-is.

Is this benchmark biased toward or against native TypeScript?

I tried hard not to let it be, and the results argue for that: the adversarial fixtures I specifically designed to stress the type checker show the smallest native advantage in the whole suite, not the largest. A biased benchmark doesn’t usually undercut its own headline number.

What’s the single biggest caveat?

Every number here is from one Windows machine. The direction of the findings (native is faster, memory is roughly at parity, gains vary a lot by workload) is probably robust elsewhere. The precise multipliers are not guaranteed to hold on different hardware or operating systems.

7. Conclusion: A Number Worth Distrusting Correctly

“10x faster” is a great headline and a lossy summary. The real story is that TypeScript 7’s native compiler is a substantial, workload-dependent improvement: dramatic on real application code, still meaningfully positive but far more modest on the adversarial patterns that stress the type checker hardest, and roughly at parity (not better) on memory. Every fixture in this benchmark got faster; none got slower.

That’s a more useful thing to know than any single multiplier, including my own “3.68x.” Distrust headline performance claims by default, including this one, and go check the fixture that actually resembles your own code.

8. References

• Full benchmark repository (raw data, methodology, README.md): https://github.com/powergr/typescript-native-compiler-benchmark
• TypeScript’s own repository: https://github.com/microsoft/TypeScript