flâneur — a map of the web's best reading

Why does tsgo use so much memory?

zackoverflow.dev · 2,554 words · saved by 1 readers

If you run tsgo on decently sized Typescript project, it’s not uncommon to see it using gigabytes of memory. Why is that? The short answer is: when multi-threading, tsgo makes a type checker per thread each type checker has its own state (types, symbols, etc.) this state is not shared as synchronizing it between threads is costly so each type checker often allocates duplicate, redundant memory in addition, allocated types are literally never freed1 It’s not uncommon for Typescript projects to have: several thousand Typescript files libraries like Zod, tRPC, Drizzle which result in many, many type instantiations recursive generic types which product a lot of transient types which are never freed When running tsgo on a large Typescript project, these type creation patterns compound and result in a lot of duplicated or unused memory. Let’s dig deeper. I’ll run tsgo on a large nextjs project with Zod, tRPC, Drizzle, all the good stuff that makes the typechecker do work. Including node_modu

5/27/2026 · 5,302 views Why does tsgo use so much memory? {pubDate.toString()} } --> If you run tsgo on decently sized Typescript project, it’s not uncommon to see it using gigabytes of memory. Why is that? The short answer is: when multi-threading, tsgo makes a type checker per thread each type checker has its own state (types, symbols, etc.) this state is not shared as synchronizing it between threads is costly so each type checker often allocates duplicate, redundant memory in addition, allocated types are literally never freed 1 It’s not uncommon for Typescript projects to have: several th

Explore this link on the map →

related reading