You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 1, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 1, 2026. It is now read-only.
[bug] tsgo --build uses extreme amounts of memory #1622
Unfortunately I don't have one to share as it crashed my remote dev machine (used 116GB of RSS before it did).
Steps to reproduce
This is probably unique to our scale here at Canva. I attempted to build one of the TS projects in our monorepo that transitively depends upon 5k+ other TS projects. It built for ~5 mins before crashing out due to excess memory usage.
Reacted by Ayron Wohletz, Shrey Sudhir, Ryan M. Poe, Umair Ahmed, Efraim Rodrigues, Miklós Kiss, Christian Vega-Munguia, Doug Ludlow and Ryan Soderberg
Sheetal Nandi (@sheetalkamat) I just tried it out again with your change included -- unfortunately still seems to be broken. memory climbed back up to 100GB RSS before the OS killed the process. we could try to take a pprof memory profile beginning of next week if you'd find it useful?
Can you try #1692 to see if it helps. You can also use --maxConcurrentProjects to change how many projects can be built simultaneously and see if that is of any help
Sheetal Nandi (@sheetalkamat) We faced the same problem (even with --noEmit) of tsgo taking more memory than tsc. Using --singleThreaded resolved the problem, while still allowing us to take advantage of the performance gains. Thanks for the tip!
Edit: One additional thing that can be tuned is GOGC (see docs) and GOMEMLIMIT (see docs). We set GOGC to 0.3 and GOMEMLIMIT to something less than our CI servers' limit
Sheetal Nandi (@sheetalkamat) have been seeing this too on a mix of individual projects or large subsets (8k projects) in our internal monorepo, how can I help test the PR? Build locally?
I might have missed where to find the branch deploy options 🙈🙏
I have the same issue in our repo, we have ~1000 ts projects, building everything in single process went up to 80GB commit size, based on error messages, didn't get much further than perhaps 5%, then crashed with oom.
Running --singleThreaded works fine, everything compiles, result is still much much faster than with tsc.
Sheetal Nandi (@sheetalkamat) Can you resurrect your change to limit the number of concurrent project builds? We have --checkers, but I think we were also wanting to add --builders to control that number.
Tomorrow, can you all try build mode with --builders 1? Given single project checking is already concurrent, we think it might be that build more concurrency may not actually matter too much anymore.
tsgo -b everything.json --singleThreaded - 3min 30sec to complete ~1000 tsconfig projects. ~30 sec to first error printed. Max commit size ~15GB
tsgo -b everything.json --builders 1 - 5 minutes without any output, i manually killed it. max commit size ~30GB (reached early, didn't grow much afterwards). For long periods the process seems to be idle for noticeable time, then work again, then again idle (cpu and mem doesn't move).
Unfortunately, very private. Perhaps if you are willing, we could try NDA path to get access to it. Overall it is just a lot of react tsx files and jest and playwright spec files, with declaration emit only. Few symlinks between packages, but mostly uses path aliases still.
btw, tsgo -b everything.json --builders 1 --checkers 1 have the same behavior as simply --builders 1 - still 30GB commit size and hangs.
Also the processes hang so that i can't even kill them via task manager - it shows access denied error.
taskkill /f /im tsgo.exe
ERROR: The process "tsgo.exe" with PID 14024 could not be terminated.
Reason: There is no running instance of the task.
ERROR: The process "tsgo.exe" with PID 36272 could not be terminated.
Reason: There is no running instance of the task.
Jake Bailey (@jakebailey)Sheetal Nandi (@sheetalkamat) - Managed to see high memory by typechecking a larger project (and hence it's dependents). Interestingly, the tsc version has different aggregate stats, and is suspiciously "fast" 🤔 So either I've cooked the test (though I tried to run clean a lot!) or something else is afoot!
When running on larger projects that went OOM, the pprof files were empty - so hopefully this is "large enough"? Let me know.
Details and profiles below, let me know if I've missed anything (or misconfigured the runs).
No rush on anything, just wanted to send while it was top of mind - happy holidays!
Sharing incase relevant- I also note that tsgolint has seen some similar performance struggles and there's some preliminary analysis pointing to resolution/strings in oxc-project/tsgolint#295 - though I'm not sure how much is tsgo, vs tsgolint's wrappers
Activity
sheetalkamat commentedon Aug 22, 2025
Can you please try #1623 and see if that helps
mjames-c commentedon Aug 22, 2025
Sheetal Nandi (@sheetalkamat) I just tried it out again with your change included -- unfortunately still seems to be broken. memory climbed back up to 100GB RSS before the OS killed the process. we could try to take a
pprofmemory profile beginning of next week if you'd find it useful?$ strings ./built/local/tsgo | grep -i 15ae26ccc mod github.com/microsoft/typescript-go v0.0.0-20250822042943-15ae26cccfb7 build vcs.revision=15ae26cccfb7cd863aa009d0171715721d6785e1johnnycheng0210 commentedon Aug 25, 2025
Sheetal Nandi (@sheetalkamat)
following up Michael James (@mjames-c) -- with profiles attached for one of our largest TS projects:
typescript-cpuprof.gz
typescript-memprof.gz
happy to provide some more profiles of smaller projects if that'll be useful as well.
sheetalkamat commentedon Aug 25, 2025
Johnny Cheng (@johnnycheng0210) can you see if you repro this if you run
--singleThreadedsheetalkamat commentedon Sep 8, 2025
Can you try #1692 to see if it helps. You can also use
--maxConcurrentProjectsto change how many projects can be built simultaneously and see if that is of any helphsource commentedon Sep 11, 2025
Sheetal Nandi (@sheetalkamat) We faced the same problem (even with
--noEmit) oftsgotaking more memory thantsc. Using--singleThreadedresolved the problem, while still allowing us to take advantage of the performance gains. Thanks for the tip!Edit: One additional thing that can be tuned is
GOGC(see docs) andGOMEMLIMIT(see docs). We set GOGC to 0.3 and GOMEMLIMIT to something less than our CI servers' limitsheetalkamat commentedon Sep 22, 2025
Can you please try out #1745 to see if it helps
Thanks
spanishpear commentedon Sep 22, 2025
Sheetal Nandi (@sheetalkamat) have been seeing this too on a mix of individual projects or large subsets (8k projects) in our internal monorepo, how can I help test the PR? Build locally?
I might have missed where to find the branch deploy options 🙈🙏
sheetalkamat commentedon Sep 22, 2025
You would need to build from #1745 to test it out
2 remaining items
Knagis commentedon Dec 9, 2025
7.0.0-dev.20251208.1
I have the same issue in our repo, we have ~1000 ts projects, building everything in single process went up to 80GB commit size, based on error messages, didn't get much further than perhaps 5%, then crashed with oom.
Running --singleThreaded works fine, everything compiles, result is still much much faster than with tsc.
jakebailey commentedon Dec 9, 2025
Sheetal Nandi (@sheetalkamat) Can you resurrect your change to limit the number of concurrent project builds? We have
--checkers, but I think we were also wanting to add--buildersto control that number.jakebailey commentedon Dec 10, 2025
Tomorrow, can you all try build mode with
--builders 1? Given single project checking is already concurrent, we think it might be that build more concurrency may not actually matter too much anymore.maxkostow commentedon Dec 10, 2025
Is that expected to impact the LSP or should there be a separate issue for the LSP?
jakebailey commentedon Dec 10, 2025
No, that is largely unrelated and not the focus of this thread. Build mode is not a part of the language server.
#2239 is closer, but I would very much suggest filing separate issues rather than commenting on existing ones if the cases aren't the same.
Knagis commentedon Dec 12, 2025
Jake Bailey (@jakebailey) I ran the test now with 7.0.0-dev.20251212.1
--clean called before both runs.
tsgo -b everything.json --singleThreaded- 3min 30sec to complete ~1000 tsconfig projects. ~30 sec to first error printed. Max commit size ~15GBtsgo -b everything.json --builders 1- 5 minutes without any output, i manually killed it. max commit size ~30GB (reached early, didn't grow much afterwards). For long periods the process seems to be idle for noticeable time, then work again, then again idle (cpu and mem doesn't move).jakebailey commentedon Dec 12, 2025
Is this codebase public? That definitely sounds like the opposite of how it should behave.
Knagis commentedon Dec 12, 2025
Unfortunately, very private. Perhaps if you are willing, we could try NDA path to get access to it. Overall it is just a lot of react tsx files and jest and playwright spec files, with declaration emit only. Few symlinks between packages, but mostly uses path aliases still.
Knagis commentedon Dec 15, 2025
btw,
tsgo -b everything.json --builders 1 --checkers 1have the same behavior as simply--builders 1- still 30GB commit size and hangs.Also the processes hang so that i can't even kill them via task manager - it shows access denied error.
spanishpear commentedon Dec 30, 2025
Jake Bailey (@jakebailey) Sheetal Nandi (@sheetalkamat) - Managed to see high memory by typechecking a larger project (and hence it's dependents). Interestingly, the
tscversion has different aggregate stats, and is suspiciously "fast" 🤔 So either I've cooked the test (though I tried to run clean a lot!) or something else is afoot!When running on larger projects that went OOM, the pprof files were empty - so hopefully this is "large enough"? Let me know.
Details and profiles below, let me know if I've missed anything (or misconfigured the runs).
No rush on anything, just wanted to send while it was top of mind - happy holidays!
tsgo
tsgo --build ./foo/bar/baz/tsconfig.app.json --extendedDiagnostics --pprofDir $HOME/tmp/tsgo_profilingExtendedDiagnostics
--builders=1
ExtendedDiagnostics
tsc
ExtendedDiagnostics
Profiles
tsgo
34030-cpuprofile.pb.gz
34030-memprofile.pb.gz
tsgo --builders=1
54771-cpuprofile.pb.gz
54771-memprofile.pb.gz
spanishpear commentedon Dec 30, 2025
Sharing incase relevant- I also note that tsgolint has seen some similar performance struggles and there's some preliminary analysis pointing to resolution/strings in oxc-project/tsgolint#295 - though I'm not sure how much is tsgo, vs tsgolint's wrappers
rubenferreira97 commentedon Jan 7, 2026
jakebailey commentedon Jan 7, 2026
sheetalkamat commentedon Jan 29, 2026
Can you please try build from #2604 to see if it helps