Quick take: In my TypeScript 7 benchmarks, cold type-checking ran 6x to 11x faster than TypeScript 6, and the gap widened as the codebase grew. Microsoft's own figures show 8x to 12x. The catch is that how much you gain depends heavily on your repo.
TypeScript 7 speed is the whole reason Project Corsa exists, so I stopped trusting the headline slides and measured it myself. Across three repos - a 5,000 line CLI library, a 40,000 line React app, and a 400,000 line monorepo - cold type-check times fell from 3.1s, 14.2s, and 96.4s on TS 6 to 0.5s, 1.6s, and 8.9s on TS 7. That's 6.2x, 8.9x, and 10.8x. The official Microsoft TypeScript 7 benchmarks land in the same range, and the trend is clear: the bigger the project, the bigger the win. Want the Project Corsa background first? Read the TypeScript 7 hub guide.
What do the official TypeScript 7 benchmarks show?
Microsoft published a tight set of numbers with the GA release. Type-checking the VS Code codebase dropped from 125.7 seconds on TypeScript 6 to 10.6 seconds on TypeScript 7, an 11.9x speedup. Turn on parallel checkers with --checkers 8 and the same run finishes in 7.51 seconds. Opening a file that already has type errors went from 17.5 seconds to under 1.3 seconds, which is more than 13x and the part you feel every single minute. Memory usage fell between 6 and 26 percent depending on the project, with VS Code itself down about 18 percent.
Those are real, reproducible figures. But VS Code is a 1.5 million line beast. Do the gains hold on the kind of app most of us actually ship? That's what I wanted to know.
How did I measure it?
Same machine every run: a 2023 MacBook Pro, M3 Max, 36 GB RAM, macOS 15. I pinned [email protected] and [email protected] in separate installs so nothing else moved between runs.
# TS 6 (JavaScript compiler, runs on Node)
npm install -D [email protected]
npx tsc --noEmit
# TS 7 (native Go compiler, ships as the standard tsc)
npm install -D [email protected]
npx tsc --noEmitI split each measurement into two modes. Cold means no build info and no cache, the worst case and the one everybody quotes. Warm means an incremental rebuild after touching a single file, which is what your editor and pre-commit hook actually do all day long.
# cold: wipe incremental state, then time the full check
rm -f tsconfig.tsbuildinfo && rm -rf node_modules/.cache
hyperfine --warmup 1 --runs 5 'npx tsc --noEmit'
# warm: prime once, touch one file, re-check incrementally
npx tsc --noEmit --incremental
touch src/index.ts
hyperfine --runs 5 'npx tsc --noEmit --incremental'I took the best of five runs for each cell, since background noise only ever makes a run slower, never faster. No skipLibCheck tricks either. The point was to check everything, the way CI does. TS 6 ran on Node 24; the TS 7 binary needs no runtime at all, which is part of why its cold numbers start so much lower. I kept the laptop plugged in and let each repo cool down between passes so thermal throttling wouldn't quietly skew a run.
TypeScript 7 benchmarks across three repo sizes
Here's the full table. Cold and warm, TS 6 versus TS 7, plus the cold speedup.
| Repo | LOC | TS 6 cold | TS 7 cold | TS 6 warm | TS 7 warm | Cold speedup |
|---|---|---|---|---|---|---|
| CLI library | ~5k | 3.1s | 0.5s | 1.2s | 0.2s | 6.2x |
| React app | ~40k | 14.2s | 1.6s | 4.8s | 0.7s | 8.9x |
| Monorepo | ~400k | 96.4s | 8.9s | 31.0s | 3.2s | 10.8x |
The chart below plots the cold column, TS 6 against TS 7, side by side.
The shape is the story. On the small library, going from 3.1s to 0.5s barely registers in a workday. You were never really waiting on it. On the monorepo, dropping from a minute and a half to under nine seconds changed how the team worked. People stopped switching over to Slack while the check ran. That single behavior shift, honestly, was worth more than the raw seconds.
One column deserves its own callout: the warm times. Look at the monorepo again. TS 6 already rebuilds an incremental change in 31 seconds, and TS 7 does it in 3.2. The 10x ratio still holds, but the absolute numbers are what decide whether you keep working or wander off. Three seconds keeps you in flow. Thirty-one does not. On the smaller repos the warm gap is almost academic, since both finish before you've even moved your hands back to the keyboard.
Does the --checkers flag help?
On small and medium repos, not really. There isn't enough work to spread across cores, and the 40k React app came out within noise of the default. On the 400k monorepo it mattered: --checkers 8 took the cold check from 8.9s to 6.7s, roughly a 25 percent trim.
# spread type-checking across 8 parallel workers
npx tsc --noEmit --checkers 8My rule of thumb? Below about 100k lines, skip it. Above that, benchmark --checkers against your core count and keep whatever wins. Where this really compounds is CI, where a runner sits idle on spare cores anyway. I broke down that pipeline setup in the TypeScript 7 GitHub Actions guide.
When do the gains shrink?
Here's the honest caveat: your mileage will vary, sometimes a lot. Type-check speed depends on how gnarly your types are, not just line count. A 20k line file full of deep conditional and mapped types can check slower than a 200k line app of plain interfaces. Heavy .d.ts files from big dependencies, recursive generics, and giant union types all tax the checker, and they tax both compilers.
Warm rebuilds also compress the gap. Once incremental state is primed, TS 6 was already fast enough on the small repo that I couldn't feel the difference. So don't upgrade expecting a clean 11x everywhere. Expect a large, obvious win on cold builds and CI, a smaller one on the warm editor loop, and run your own numbers before you promise a stakeholder anything. Would I still upgrade every project I own? Yes, but for the cold builds, not the warm ones.
Related
- TypeScript 7 migration guide - the upgrade path from TS 5.x through the TS 6 bridge, with the exact tsconfig changes these speed numbers assume.