Benchmarks
Speed is the experiment's original motivation, so every major compiler checkpoint carries comparable fixtures rather than relying on impressions from one file. These are five-run medians recorded on 17 August 2026 with TypeScript 7.0.2.
| Workload | tscc | tsc --noCheck | Approx. ratio |
|---|---|---|---|
| Small startup | 1.575 ms | 122.799 ms | 78.0× |
| 100 basic files | 6.827 ms | 127.774 ms | 18.7× |
| 500 basic files | 25.529 ms | 155.670 ms | 6.1× |
| 100 feature-heavy files | 8.480 ms | 130.592 ms | 15.4× |
| 100 advanced files | 9.391 ms | 131.424 ms | 14.0× |
What these numbers mean
They demonstrate startup/project-transpilation potential for the current implementation on this machine. They do not mean tscc performs all the work TypeScript performs faster. tscc's semantic work remains deliberately bounded, lib processing differs, and the supported compiler surface is smaller. Older snapshots showed much larger ratios because their installed TypeScript process was slower; dated raw comparisons are more honest than preserving the best historical headline.
Why compare with --noCheck?
tsc --noCheck is the more honest reference for transpilation-oriented work because full tsc includes semantic checking that tscc does not implement. Full tsc is still recorded to show the practical end-to-end TypeScript cost.
Fixture families
The benchmark tree includes a tiny startup case, 100 basic files, feature-heavy/advanced syntax, 100 TSX files, a 200-module ESM project and a 200-module CommonJS project. New compiler functionality is added to dedicated fixtures so performance cannot hide behind an unrepresentative hello-world benchmark.
What I watch for
Absolute latency matters, but trends matter more: repeated lexing, filesystem canonicalization, retaining unnecessary project state, regex-heavy config parsing and whole-project passes can each turn a tiny compiler into a slow one. Several architectural changes have already been driven by benchmark regressions.