Declaration emit spends significant CPU in getAliasForSymbolInContainer / getAlternativeContainingModules #63830
Description
Summary
While running tsgo -b -f on a large private project, declaration emit spends a significant amount of CPU time in symbol accessibility logic, especially getAlternativeContainingModules and getAliasForSymbolInContainer.
The project source cannot be shared, but I can provide sanitized pprof output and/or raw Go pprof profiles after checking that they do not contain private TypeScript source contents.
Environment
- typescript-go commit:
804eb7a1a1a9b0722af207412921cc025dfbbd5a - tsgo version:
7.0.0-dev - Go version:
go1.26.0 linux/amd64 - OS: Linux amd64
- Command shape:
./built/local/tsgo -b <private project> -f
Observed performance
Using /usr/bin/time -v:
Elapsed wall time: 43.40s
User time: 196.33s
System time: 10.24s
CPU: 475%
Maximum resident set size: 4,264,424 KB
CPU profile highlights
Profile command:
./built/local/tsgo -b <private project> -f --pprofDir <profile-dir>
go tool pprof -top ./built/local/tsgo <profile-dir>/<pid>-cpuprofile.pb.gz
go tool pprof -top -cum ./built/local/tsgo <profile-dir>/<pid>-cpuprofile.pb.gz
Relevant excerpt:
Duration: 43.09s
Total samples: 208.55s
flat flat% cum cum%
3.00s 1.44% 42.62s 20.44% github.com/microsoft/typescript-go/internal/checker.(*Checker).getAlternativeContainingModules
1.36s 0.65% 37.27s 17.87% github.com/microsoft/typescript-go/internal/checker.(*Checker).getAliasForSymbolInContainer
0.15s 0.07% 21.60s 10.36% github.com/microsoft/typescript-go/internal/checker.(*Checker).getSymbolIfSameReference
0.26s 0.12% 12.96s 6.21% github.com/microsoft/typescript-go/internal/checker.(*Checker).resolveSymbolEx
7.99s 3.83% 7.99s 3.83% github.com/microsoft/typescript-go/internal/ast.IsNonLocalAlias
The cumulative profile suggests declaration emit repeatedly checks whether a symbol is accessible through alternative containing modules, and repeatedly scans exports in getAliasForSymbolInContainer.
Allocation profile highlights
Total allocated: ~19.68GB
Maximum RSS from /usr/bin/time: ~4.26GB
Local experiment
I tested a conservative local prototype that caches, per checker/container, the export candidates grouped by the same resolved/merged target symbol. It does not cache the final selected alias directly; it still sorts only the candidates for the currently queried target, to preserve the old selection behavior as closely as possible.
On the same private project:
Before: 43.40s wall, 4,264,424 KB max RSS
After: 37.64s wall, 4,210,296 KB max RSS
That is about a 13% wall time improvement on this workload.
Relevant tests passed locally:
GOCACHE=/tmp/tsgo-go-cache go test ./internal/checker
Question
Would a per-container cache for alias candidates in getAliasForSymbolInContainer, or another cache around this symbol accessibility path, be acceptable? I am happy to share sanitized pprof text output, and possibly raw .pb.gz pprof files if that is useful.
Activity
jakebailey commentedon May 30, 2026
The pprof files produced by the published package won't contain anything sensitive; you should be able to share them as-is.
(The only info they'd contain is if you built us from source and didn't do
-trimpathand then contain paths to your tsgo checkout; still nothing related to your project.)Zzzen commentedon May 31, 2026
Hope this helps, and let me know if the matching memory profile would be useful too.
3401843-cpuprofile.pb.gz
jakebailey commentedon Jun 1, 2026
Is this a regression? Or was it always this bad? I know I tried to improve this in microsoft/typescript-go#3232, so I'm curious
Zzzen commentedon Jun 2, 2026
I checked older points as well. This does not look like a recent regression introduced around microsoft/typescript-go#3232. On the current project workload, the commit before microsoft/typescript-go#3232 and microsoft/typescript-go#3232 itself are both around 42s wall time. A three-month-old commit and a six-month-old commit are actually slower, but they no longer build the current repo cleanly and exit with diagnostics, so those numbers are not perfectly apples-to-apples. Still, the data suggests the expensive behavior was already present before microsoft/typescript-go#3232; microsoft/typescript-go#3232 only has noise-level impact on this workload.
jakebailey commentedon Jun 2, 2026
By chance could you also profile this with tsc?
https://www.npmjs.com/package/pprof-it but this isn't safe to send without the sanitization setting, so a screenshot of the frame graph is probably also fine.
jakebailey commentedon Jun 2, 2026
Can you try microsoft/typescript-go#4176? (I see you have your own PR but I'm hoping this simpler change works)
Zzzen commentedon Jun 2, 2026
I profiled the same build graph with tsc using pprof-it, with PPROF_SANITIZE=on.
Command:
TypeScript: 5.8.2
The tsc build did not complete cleanly; it exited 2 with TS5095 and many TS2742 diagnostics. The profiles were still written successfully and sanitized.
Wrapped command time:
Time profile sampled 291.84s. Main flat hotspots:
The largest cumulative phase is declaration emit:
Heap profile total was about 3.8GB. The biggest flat allocations are mostly AST/symbol/parser structures:
So the module-specifier / symbol-accessibility path does show up in tsc as well, but in this tsc profile it is not the only large cost; declaration emit, template-literal type matching, and GC are also very prominent.
Zzzen commentedon Jun 2, 2026
Tested microsoft/typescript-go#4176 in isolated worktrees, comparing the PR head against its direct parent so only the PR’s 5-line change is measured.
Command:
Results:
Conclusion: microsoft/typescript-go#4176 does not improve wall time on this workload. Average wall is effectively unchanged: 42.19s parent vs 42.22s PR.
It may modestly reduce peak RSS: average RSS dropped from 4,205,484 KB to 4,028,658 KB, about 173 MiB / 4.2%, though with only two samples I’d phrase this cautiously.
jakebailey commentedon Jun 2, 2026
But, microsoft/typescript-go#4102 works? I'm not sure you showed a bench for this.
Is this codebase definitely unavailable, even under NDA?
Zzzen commentedon Jun 2, 2026
I'm really sorry, but I'm afraid the codebase isn't available for sharing, even under NDA. It's proprietary commercial code, and getting approval would involve a very complex and lengthy internal process. On top of that, it heavily depends on our internal libraries and infrastructure, which makes sharing it extremely difficult in practice.
I truly appreciate your understanding and interest! Let me know if there's anything else I can help you with.
Zzzen commentedon Jun 2, 2026
PR microsoft/typescript-go#4102 works well based on my local benchmarking.
TypeScript-Go PR microsoft/typescript-go#4102 Benchmark
Benchmark target:
Compared commits:
804eb7a1a11642bbd39a(Cache alias candidates for symbol accessibility)Each build was run 5 times in an interleaved order: parent, PR, parent, PR, and so on. The runs used isolated worktrees and the same forced build command to avoid build-cache skew.
Results
Summary
Median wall time:
Conclusion
PR microsoft/typescript-go#4102 clearly improves this workload. Across 5 interleaved forced-build runs, it reduces wall time by about 14-15% and user CPU time by about 8%.
The tradeoff is a modest increase in peak memory usage. In this 5-run sample, max RSS increased by about 93 MiB on average, or roughly 2.3%.
Overall, the PR looks beneficial for this workload: the speedup is stable and much larger than the observed memory increase.
jakebailey commentedon Jun 2, 2026
It would be good to be able to get access to this, I'm not really sure I like the way microsoft/typescript-go#4102 looks...
Zzzen commentedon Jun 11, 2026
Thanks, I understand. Unfortunately I can't provide access to the project or source code, since it is a private/proprietary workload.
I realize that makes the issue harder to evaluate. What I can provide is more sanitized evidence:
pprof -top/pprof -top -cumoutput, allocation profile summaries, and additional benchmark runs. I can also run any alternative patch or experiment you suggest against the same workload and report the results.If the current shape of microsoft/typescript-go#4102 does not look right, I am happy to rework it or treat it mainly as evidence for the hotspot rather than the final implementation direction.
resure commentedon Sep 26, 2026
A public synthetic repro is available in #64464. It exercises the same symbol-accessibility hotspot while an incremental
--noEmitcheck computes declaration signatures: on 7.0.2, a first comment-only edit takes 34.3 s versus 0.57 s for a full check, with about 79% of sampled CPU ingetAlternativeContainingModules. The report also includes results for 5.4.5, 6.0.3 and 7.1 nightly.The build shape differs from the forced declaration build here, so this does not establish that both workloads have the same cause. It may provide a shareable workload for evaluating the proposed fixes without access to the private project.