TypeScript-Go Performance Issue

[ChrisWiles]

TypeScript-Go (tsgo) is performing much slower than expected — only about 28% faster than tsc (57s vs. 79s), whereas the promise was a 10x improvement (~7.9s). This is significantly below expectations.

---

Performance Results

Tool	Duration	Improvement
tsc	79s	–
tsgo	57s	~28% faster

---

Environment

• CI Platform: GitHub Actions (ubuntu-latest, x86_64)

• Node.js: v20.15.0

• Memory: Standard runner allocation

• Project: Large React Native (Expo bare)

• Lines of Code: ~322K

• TypeScript: 5.8.3

• TypeScript-Go: @typescript/native-preview@7.0.0-dev.20250802.1

---

TypeScript Configuration

• Strict Mode with multiple strict flags

• Path Mapping: (@kojo/*, @graphql/*, etc.)

• Target: ES2023, JSX: react-jsx

• Incremental Compilation: Enabled

• Skip Lib Check: Enabled

---

Command Setup

{
  "lint:typecheck": "node --max-old-space-size=8192 ./node_modules/.bin/tsc --noEmit",
  "lint:typecheck:tsgo": "tsgo --noEmit"
}

Any ideas or suggestions?

[jakebailey]

We would need the actual repo to check, but you could use --pprofDir to collect profiles of how it's currently behaving.

[jakebailey]

I'll note that the GHA runners are not particularly fast.

[ChrisWiles]

We would need the actual repo to check, but you could use --pprofDir to collect profiles of how it's currently behaving.

> tsgo --noEmit --pprofDir ./tsgo-profiles
CPU profile: /home/runner/work/mobile/mobile/tsgo-profiles/2227-cpuprofile.pb.gz
Memory profile: /home/runner/work/mobile/mobile/tsgo-profiles/2227-memprofile.pb.gz
real	0m53.820s
user	1m36.837s
sys	0m6.296s

I don't know how to read those files but I asked Claude Code to study them and it wasn't very helpful either

2227-cpuprofile.pb.gz
2227-memprofile.pb.gz

⏺ TypeScript-Go Performance Analysis Report

Executive Summary

TypeScript-Go fails to achieve the promised 10x performance improvement on large React Native projects, delivering only a 28% improvement (79s → 57s) instead of the expected 10x improvement (79s → 7.9s).
Comprehensive profiling reveals fundamental performance bottlenecks in type system processing and memory management.

Performance Comparison

Metric	tsc (baseline)	TypeScript-Go	Improvement	Expected (10x)
Runtime	1m 16.9s (76.9s)	57.1s	28%	7.9s
CPU Time	1m 38.7s	1m 43.2s	-4%	~16s
Memory Peak	~4GB	5.4GB	-35%	<1GB

CPU Profile Analysis

Overall CPU Statistics

• Total Runtime: 53.25 seconds
• CPU Samples: 102.42 seconds (192.34% utilization)
• Multi-core Usage: ~2 cores effectively utilized
• Profile Coverage: 76.96% of execution time captured

CPU Time Distribution

1. Memory Management Overhead (25.5% CPU time)

Function	Flat Time	Cumulative Time	% of Total
runtime.findObject	9.47s	12.34s	12.05%
runtime.scanobject	2.88s	12.42s	12.13%
runtime.bulkBarrierPreWrite	1.68s	13.89s	13.56%
runtime.wbBufFlush1	1.59s	9.58s	9.35%

Analysis: Garbage collection consumes over 25% of CPU time, indicating excessive memory pressure and object allocation patterns that overwhelm Go's GC.

2. Type System Operations (45% CPU time)

Core Type Processing

Function	Flat Time	Cumulative Time	% of Total
(*Checker).instantiateTypeWithAlias	0.45s	54.44s	53.15%
(*Checker).getReducedType	0.56s	15.29s	14.93%
(*Checker).addTypesToUnion	0.46s	18.77s	18.33%
(*Checker).getPropertyOfTypeEx	0.48s	15.28s	14.92%

Union/Intersection Type Processing

Function	Flat Time	Cumulative Time	% of Total
(*Checker).getUnionTypeWorker	0.08s	22.65s	22.11%
(*Checker).getPropertiesOfUnionOrIntersectionType	0.11s	15.10s	14.74%
(*Checker).getUnionOrIntersectionProperty	0.10s	13.51s	13.19%
(*Checker).getIntersectionTypeEx	0.07s	29.01s	28.32%

Critical Finding: Type instantiation alone consumes 53.15% of total runtime, indicating algorithmic complexity issues with React Native's complex type patterns.

3. Hash Map & String Operations (8% CPU time)

Function	Flat Time	Cumulative Time	% of Total
runtime.mapaccess1_faststr	1.77s	6.64s	6.48%
strings.(*Builder).WriteByte	0.57s	2.69s	2.63%
runtime.mapassign_faststr	0.78s	7.13s	6.96%

Memory Profile Analysis

Overall Memory Statistics

• Total Allocated: 5.411 GB
• Profile Coverage: 87.70% of allocations captured
• Allocation Rate: ~104 MB/second
• Major Allocators: 67 functions analyzed

Memory Allocation Distribution

1. Type System Memory Consumption (67% of allocations)

Union/Intersection Processing

Function	Allocated	% of Total	Cumulative
(*Checker).getUnionOrIntersectionProperty	578.19 MB	10.68%	1.337 GB (24.70%)
(*Checker).getPropertiesOfUnionOrIntersectionType	82.43 MB	1.52%	1.788 GB (33.04%)
instantiateList[Type]	39.50 MB	0.73%	1.673 GB (30.91%)

Type Creation and Mapping

Function	Allocated	% of Total	Cumulative
(*Checker).mapTypeEx	63.68 MB	1.18%	1.299 GB (24.00%)
(*Checker).getIntersectionTypeEx	51.67 MB	0.95%	1.104 GB (20.40%)
(*Checker).getObjectTypeInstantiation	13.03 MB	0.24%	1.235 GB (22.81%)

2. Collection and String Operations (18% of allocations)

Dynamic Collection Growth

Function	Allocated	% of Total
slices.Grow[Type]	405.75 MB	7.50%
slices.Insert[Type]	148.95 MB	2.75%
slices.Grow[Symbol]	128.65 MB	2.38%

String Processing

Function	Allocated	% of Total
strings.(*Builder).WriteByte	238.53 MB	4.41%
strings.(*Builder).grow	163.52 MB	3.02%
strings.(*Builder).WriteString	56.00 MB	1.03%

3. Framework-Specific Allocations (15% of allocations)

React Native Type Processing

Function	Allocated	% of Total
(*Checker).getTemplateLiteralType	83.02 MB	1.53%
(*Checker).checkObjectLiteral	43.53 MB	0.80%
(*Checker).getLiteralTypeFromProperties	89.24 MB	1.65%

Root Cause Analysis

1. Algorithmic Complexity Explosion

Union/Intersection Type Scaling Issues:

• React Native components with complex prop types create massive union/intersection types
• Type property resolution exhibits O(n²) to O(n!) complexity patterns
• Single function (instantiateTypeWithAlias) consumes 53% of total runtime

Memory Allocation Patterns:

• 5.4GB allocated in 53 seconds indicates excessive temporary object creation
• Type system creates numerous short-to-medium-lived objects that stress Go's GC
• Union type processing alone allocates 1.8GB (33% of total memory)

2. Garbage Collection Inefficiency

GC Overhead Analysis:

• 25.5% of CPU time spent on garbage collection vs. 0% in tsc
• Go's GC optimized for web servers, not type checker memory patterns
• Object lifetime patterns mismatch GC generational assumptions

Memory Pressure Indicators:

• High allocation rate (104MB/s) triggers frequent GC cycles
• runtime.findObject consuming 9.25% CPU indicates GC scanning overhead
• Write barriers (bulkBarrierPreWrite) add 13.56% CPU overhead

[lukeapage]

We have a very large over a million lines of code repo and we are seeing big improvements- 4-6x faster so maybe it’s incremental (w have disabled) or maybe it’s something else in your repo.

[DanielRosenwasser]

My understanding from these profiles is that you have some computationally intense work across large union and intersection types, and this work is probably triggered across every checker that gets spawned. getPropertiesOfUnionOrIntersectionType is indirectly triggering a lot of allocation (1.75GB!) which is in turn also putting a lot of stress on the GC. tsgo will be quite a bit faster, but there is only so much to be gained when hitting these pathological edge cases.

I'd be curious to see what the differences you see are between tsc --extendedDiagnostics and tsgo --diagnostics.

What I would also recommend is using tsc to generate a performance trace and try to figure out which parts of your codebase are triggering the most work.

We have an entire page with details here, but you could run

tsc -p your-tsconfig.json --generateTrace traceDir

To generate the trace. You could play with our analyze-trace tool and tweak the parameters to see the hot spots of your codebase:

# Using our CLI analyze-trace tool
# Read up more here: https://www.npmjs.com/package/@typescript/analyze-trace
npm install -g @typescript/analyze-trace
analyze-trace traceDir

and you could load up the trace in about://tracing in Edge or Chrome to see a flame graph of what work is happening (our wiki page explains how).