TypeScript 7 is described as roughly ten times faster than TypeScript 6 in many workloads. Slack reportedly reduced type-checking time from about 7.5 minutes to 1.25 minutes and removed a substantial part of its merge-queue delay. Those numbers show what is possible, but they are not a prediction for every repository.

A useful benchmark must prove that both compilers checked the same project, produced equivalent diagnostics, and ran under comparable CPU, memory, cache, and filesystem conditions.

Quick answer

Measure at least five cold runs and five warm runs on the same commit and runner class. Compare medians, diagnostics, peak memory, generated declarations, and total CI critical-path time. Do not report only the fastest run.

hyperfine \
  --warmup 1 \
  --runs 5 \
  --prepare 'rm -f .tsbuildinfo && rm -rf dist' \
  'npx tsc6 --noEmit --pretty false' \
  'npx tsc --noEmit --pretty false'

If hyperfine is unavailable, use /usr/bin/time and save every raw run. Keep compiler output separate from timing output.

Freeze the comparison inputs

Use one commit, lockfile, tsconfig, Node.js version, operating system image, CPU allocation, and environment variables. Disable unrelated jobs on the runner. Shared CI machines can add enough noise to hide meaningful differences.

Record:

node --version
npx tsc --version
npx tsc6 --version
uname -a
git rev-parse HEAD

For a monorepo, list project references in the same order and ensure both commands find the same configuration. A compiler that accidentally skips a package will look impressively fast.

Separate cold and incremental performance

Cold checks matter for clean CI runners. Incremental checks matter for local development and persistent build workers. Do not combine them into one average.

For cold runs, remove .tsbuildinfo and emitted output. For incremental runs, make one controlled source change, then time the affected rebuild. Repeat with changes in a leaf package, a shared type package, and a widely imported package.

Measure project loading separately from checking if the tool exposes useful diagnostics. A faster startup can dominate small projects while type analysis dominates large ones.

Verify equivalent work

Capture diagnostics from both compilers and compare normalized output. Investigate every difference instead of deleting it from the benchmark.

If the project emits code, build declarations and JavaScript into separate directories:

npx tsc6 --outDir .bench/ts6
npx tsc --outDir .bench/ts7
diff -ru .bench/ts6 .bench/ts7

Some ordering differences may be intentional, especially around TypeScript 6’s stableTypeOrdering. Explain accepted differences explicitly. Never use output equality as the only correctness test; run the application and downstream package tests.

Measure what affects developers

Compiler wall time is only one part of CI. Record queue time, dependency installation, code generation, linting, tests, packaging, and the merge gate’s total duration. A 60-second compiler saving changes little if a 20-minute integration suite remains the critical path.

For editors, measure time to first diagnostics, rename, references, and auto-imports in a representative workspace. The new language server may create more human time savings than the command-line compiler.

Track peak memory and CPU. A faster compiler that requests more parallel CPU may behave differently on a constrained runner than on a developer workstation.

Report a range and the method

A credible result says:

On five clean Linux runners with two vCPUs, the median no-emit check fell from 142 seconds to 31 seconds. Diagnostics matched. Peak memory changed from X to Y. The full required CI path fell from 11.2 to 9.3 minutes.

Publish raw values and the benchmark script. Avoid “7x faster” without the original duration, repository shape, runner, or correctness check.

Publish the failed runs as well as the median. That lets reviewers see variance and prevents a single unusually fast sample from becoming the headline. Repeat the benchmark after a representative month of code growth; compiler value is most useful when it holds as the project graph expands.

Keep the runner image and resource limits pinned during comparison.

Primary references

The goal is not to prove TypeScript 7 is fast; the project team already provides strong evidence of that. The goal is to learn where it changes your delivery system and to preserve enough detail that another engineer can reproduce the result.