Run this yourself. The script that produced these numbers, and that will produce yours:
typescript-7-benchmark/in the Coding Dunia code-examples repo. It installs both compilers, type-checks a generated project with each, and prints your own CPU, Node version and date alongside the table.
Quick take: In my own TypeScript 7 benchmarks on a 4-core Linux container, full type-checking ran 4.4x to 5.8x faster than TypeScript 6. The time tracked the imported type surface, not line count: a 2.4k-line package checked slower than a 7k-line app. Microsoft's own figures show 8x to 12x on much bigger codebases. How much you save 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 on the three TypeScript workspaces of the monorepo that builds this site. Type-checking with tsc from [email protected] versus the native tsc from [email protected], median times fell from 4.98s, 2.64s, and 6.19s on TS 6 to 1.14s, 0.47s, and 1.07s on TS 7. That's 4.4x for a small API-automation package, 5.6x for an Astro dashboard, and 5.8x for a 74k-line shared library. Notice what didn't happen: nothing hit Microsoft's 10.4x headline, because these repos are a fraction of VS Code's size and fixed costs weigh more. 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 77.8 seconds on TypeScript 6 to 7.5 seconds on TypeScript 7, a 10.4x speedup. Enabling --checkers on a multi-core CI runner trims that further, though Microsoft hasn't published an exact per-flag figure for that specific run, so treat any more granular number you see quoted elsewhere with caution. Editor responsiveness on files with existing type errors improved noticeably too, since the checker no longer has to walk the whole project on a self-hosted JavaScript implementation.
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.
One note on reading multipliers, here and everywhere else. Every speedup number is tied to one specific repo and one machine. Microsoft's 10.4x is VS Code on their hardware; the roughly 10x quoted in the GA announcement summary comes from different codebases; the 4x to 6x below is this site's own monorepo on a 4-core container. The multipliers differ because the repos differ, not because anyone's numbers are wrong. The only figure that matters for you comes from running both compilers on your own code, which takes about five minutes with the commands below.
How did I measure it?
Same machine every run: a 4-core Linux container with 16 GB RAM, the same class of box that builds and deploys this site. Node 22.22 runs the TS 6 compiler; the TS 7 binary is native Go and needs no Node at all. TS 6 is [email protected], the last JavaScript-based compiler line. TS 7 is [email protected], the GA release, where the native compiler ships as the ordinary tsc:
# TS 6 (JavaScript compiler, runs on Node)
npm install -D typescript@6
./node_modules/.bin/tsc --noEmit
# TS 7 (native Go compiler, no runtime needed)
npm install -D typescript@7
./node_modules/.bin/tsc --noEmitI ran --noEmit five times per compiler per repo and timed each with a plain shell timer, not hyperfine (it wasn't installed). I report the median of the five runs; the spread within a compiler stayed under 10 percent, apart from one outlier the median ignores anyway. Both compilers ran against identical tsconfig files (moduleResolution: "bundler", skipLibCheck: true, the settings these projects already use in CI) and reported the exact same error count on each repo, 0, 6, and 94, so both were demonstrably doing the same work. Here's the raw run log, milliseconds per full check:
dom-manager ts6 4977 4944 4933 5056 5501
dom-manager ts7 1136 1083 1187 1333 1086
dashboard ts6 2630 2670 2800 2616 2635
dashboard ts7 484 442 425 473 481
shared ts6 6160 6395 6185 6305 6100
shared ts7 1063 1093 1066 1049 1066TypeScript 7 benchmarks across three real repos
The three repos are the three TypeScript workspaces of the Yarn monorepo behind this site: a small Gmail-and-Jira automation package (dom-manager), an Astro analytics dashboard, and the shared blog toolkit library that renders every page you're reading. Real production code, warts included. LOC counts source .ts only, excluding tests, .d.ts, and node_modules.
| Repo | source LOC | TS 6 median | TS 7 median | Speedup |
|---|---|---|---|---|
| automation package | ~2.4k | 4.98s | 1.14s | 4.4x |
| Astro dashboard | ~7k | 2.64s | 0.47s | 5.6x |
| shared library | ~74k | 6.19s | 1.07s | 5.8x |
The surprise is the smallest repo. At 2.4k lines the automation package should be the quickest check on the table, yet it takes almost twice as long as the dashboard, which has three times the code. Why? It imports the googleapis client, and that one dependency drags an enormous declaration-file graph into every check. Line count didn't predict the time; the imported type surface did. The same repo also gained the least from TS 7, 4.4x against 5.8x, because parsing and binding that mountain of declarations is work no compiler rewrite can skip. The chart shows the per-repo speedups.
The shape is the story, and it isn't the one the slides imply. None of these repos hit Microsoft's 10.4x, and none should: that figure comes from a 1.5 million line codebase where checker throughput dominates and fixed startup costs vanish. On repos this size you get a very consistent 4x to 6x instead. Still transformative in absolute terms. A 6-second check dropping to 1 second turns type-checking from a pause you feel into something you stop noticing, and the whole monorepo now checks in under 3 seconds total. Scale that up to a million-line codebase like the one Microsoft measured and the workflow shift becomes the whole point, not the raw seconds.
One honest caveat on my numbers: I measured full checks, not --incremental rebuilds, and the filesystem cache was warm for every run, so treat these as steady-state figures, not cold CI starts. Warm here means the OS file cache, not TypeScript's own build-info cache. An incremental editor loop would be quicker on both compilers, and I didn't isolate it, so I won't invent a figure for it. If the tight edit-save-recheck loop is your main workflow, benchmark that specifically on your own project.
Does the --checkers flag help?
On the small-to-medium repos I ran, not really. There isn't enough work to spread across cores when the single-threaded check already finishes in under a few seconds. Where it shows is Microsoft's own data: the VS Code check dropped from 77.8s to 7.5s at default settings, and --checkers improves further on a machine with more cores than a typical laptop, though the exact per-flag number for VS Code specifically isn't published. It's a big-monorepo optimization, not a general speed knob.
# spread type-checking across 8 parallel workers
npx tsc --noEmit --checkers 8My rule of thumb? Below roughly 100k lines, skip it; my repos were nowhere near needing 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.
Repo character compresses or stretches the gap. The declaration-heaviest repo I tested, the googleapis-importing automation package, saw the smallest win at 4.4x precisely because its bottleneck is chewing through a huge dependency type graph, which the Go rewrite speeds up less than plain checking. So don't upgrade expecting a clean 11x everywhere. Expect a large win on heavy full checks and CI, a smaller one where the check was already fast, and the least on type-computation-heavy code. Run your own numbers before you promise a stakeholder anything. Would I still upgrade every project I own? Yes, without hesitation.
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.
- TypeScript 7 monorepo migration - the project-references and CI-cache setup that compounds these speed numbers across packages.
- TypeScript 7 Migration Readiness Checker - score your own tsconfig.json before you run these benchmarks yourself.