TypeScript 6 vs 7 on type-fest

Abstract

How much faster does TypeScript 7 type-check a real, type-heavy library than TypeScript 6, how much of the gain comes from the native compiler rather than parallel checking, and what happens to memory? type-fest was checked at a pinned commit with TypeScript 6.0.3 and 7.0.2 on an Apple M3 Pro, with a discarded warm-up per condition and interleaved runs. TypeScript 7 checked the library sources 3.5× faster (2.6× from the native compiler alone, 1.3× from parallel checking) and the full suite with type tests 5.3× faster, while peaking higher in memory (11.6 GiB against 10.4 GiB). The main limit: one library, and only one machine measured with this protocol so far, with other applications open.

Key numbers

1Introduction

2Method

Subject

Environment and protocol, per machine

Metrics

Check time

The "Check time" line printed by tsc --extendedDiagnostics, in seconds: the time spent in the type checker only.

Total time

The "Total time" line printed by tsc --extendedDiagnostics, in seconds: parsing, binding and checking together.

Median

The middle value of the measured runs, or the mean of the two middle values for an even count. Every reported figure is a median.

Range

The fastest and slowest measured runs, shown as whiskers on the charts.

IQR

Interquartile range, Q3 minus Q1, with quartiles by linear interpolation between order statistics.

CV

Coefficient of variation: sample standard deviation divided by the mean. Above 5%, the cause is investigated and logged.

Peak memory

Peak resident memory (RSS) from /usr/bin/time -l, field "maximum resident set size", of the largest process: the Node.js process for TypeScript 6, the native compiler for TypeScript 7.

Gain

Ratio of two median check times. The native part compares TypeScript 6 with TypeScript 7 single-threaded; the parallel part compares single-threaded with the default mode. Their product is the total gain.

The full protocol is on the method page.

3Results

4Discussion

5Limitations and threats to validity

• Types and Instantiations differ between TypeScript 6 and 7 on identical code, so never compare these counters across compilers. TypeScript 7's counters also vary slightly from run to run on the full suite, single-threaded included; on the library sources they are identical across runs.
• Memory is peak resident memory (RSS) from /usr/bin/time -l, field "maximum resident set size", of the largest process: the Node.js process for TypeScript 6, the native compiler for TypeScript 7 (its launcher replaces itself with the native binary). It is not the compiler's own "Memory used" line, which for TypeScript 6 is the V8 heap.
• Out of memory means Node.js's default heap limit (4.0 GiB here), not the machine's RAM: TypeScript 6 aborted with "Reached heap limit" at 4.2 GiB RSS, and completed with --max-old-space-size=16384.
• One library (type-fest at one commit), check time only: no emit, watch mode or editor latency.
• The two machines differ by CPU as well as core count, so compare conditions within a machine; the comparison between machines is indicative only. On the 1-core Intel Xeon, parallel checking gives 1.0× (0.9× to 1.1×) and the native compiler 4.0×.
• The Intel Xeon results use the earlier protocol: 3 runs, no warm-up, not interleaved, no RSS. The Apple M3 Pro results use a discarded warm-up per condition and interleaved runs, with other applications open (load average 3.0 to 5.0). The full-suite runs stay noisy: up to 6.7% coefficient of variation.
• The checker series was measured with other applications open (load average 3.0 to 4.2), and in a separate series from the default mode: the comparison between --checkers 8 and the default mode crosses two series.
• Results come from one machine per session: compare conditions within the same machine only.

6Conclusion and recommendations

On an Apple M3 Pro (12 cores), TypeScript 7.0.2 checked the type-fest sources 3.5× faster than TypeScript 6.0.3 (0.484 s vs 1.67 s): 2.6× comes from the native compiler alone (single-threaded) and 1.3× from parallel checking. On the full suite with type tests, TypeScript 6 stops at Node.js's default heap limit (4.0 GiB); with a 16 GiB heap it finishes in 74.6 s, against 14.1 s for TypeScript 7 (5.3× faster), but TypeScript 7 peaks higher in memory (11.6 GiB RSS vs 10.4 GiB). Stays open until a second machine is measured with the same protocol.

Recommendations

1. Expect most of the gain even on small CI runners: it comes from the native compiler, not from the number of cores.
2. Before switching a heavy type-test suite, measure its peak memory with TypeScript 7 and size CI runners on it, not on check time alone.
3. On machines with many cores, try --checkers: the default mode did not use all of them here.
4. Measure your own codebase with the same protocol before deciding: one library is not your project.

7Reproduce

8Data

• 2026-11-11-darwin-12cores-sources.jsonApple M3 Pro, 12 cores
• 2026-11-11-darwin-12cores-checkers.jsonApple M3 Pro, 12 cores
• 2026-11-11-darwin-12cores-full-ts6-default-heap.jsonApple M3 Pro, 12 cores
• 2026-11-11-darwin-12cores-full.jsonApple M3 Pro, 12 cores
• 2026-11-11-darwin-12cores-full-extra.jsonApple M3 Pro, 12 cores
• 2026-11-03-linux-1cores.jsonIntel Xeon, 1 core
• 2026-11-09-darwin-12cores.jsonApple M3 Pro, 12 cores, superseded

All raw files: results folder on GitHub. Everything shown on this page: data.json.

9Changelog

1. Nov 11, 2026

   First published at 4.0×; corrected to 3.5× after adding a warm-up run and interleaving.