Skip to content

Performance regression for declaration emit of an oversized inferred type #63966

Closed

Description

🔎 Search Terms

TS7056 memory, declaration emit OOM, "inferred type of this node exceeds the maximum length", DeepCloneNode serializedTypes, NodeBuilder declaration emit memory, typescript-go TS7056 RSS

🕗 Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about declaration emit and large inferred types
  • Reproduced on 7.1.0-dev (main, ./built/local/tsc) vs TypeScript 6.0.3 (./node_modules/typescript/bin/tsc). Both report the same TS7056 and emit no .d.ts. The Go compiler uses ~6× the memory and is 5.8x slower.
  ┌──────────────────────┬──────────┬────────┬──────────────────┐
  │ version              │ peak RSS │ wall   │ result           │
  ├──────────────────────┼──────────┼────────┼──────────────────┤
  │ 5.9.3                │ 0.51 GB  │ 0.97 s │ TS7056, no .d.ts │
  ├──────────────────────┼──────────┼────────┼──────────────────┤
  │ 6.0.3                │ 0.41 GB  │ 0.66 s │ TS7056, no .d.ts │
  ├──────────────────────┼──────────┼────────┼──────────────────┤
  │ 7.0.0-dev.20260707.2 │ 2.38 GB  │ 3.68 s │ TS7056, no .d.ts │
  ├──────────────────────┼──────────┼────────┼──────────────────┤
  │ 7.0.1-rc             │ 2.25 GB  │ 3.51 s │ TS7056, no .d.ts │
  ├──────────────────────┼──────────┼────────┼──────────────────┤
  │ 7.0.2                │ 2.25 GB  │ 3.49 s │ TS7056, no .d.ts │
  ├──────────────────────┼──────────┼────────┼──────────────────┤
  │ main 7.1.0-dev       │ 2.42 GB  │ 3.41 s │ TS7056, no .d.ts │
  └──────────────────────┴──────────┴────────┴──────────────────┘

⏯ Playground Link

N/A

💻 Code

let x0 = { v: 1 };
let x1 = { a: x0, b: x0, c: x0 };
let x2 = { a: x1, b: x1, c: x1 };
let x3 = { a: x2, b: x2, c: x2 };
let x4 = { a: x3, b: x3, c: x3 };
let x5 = { a: x4, b: x4, c: x4 };
let x6 = { a: x5, b: x5, c: x5 };
let x7 = { a: x6, b: x6, c: x6 };
let x8 = { a: x7, b: x7, c: x7 };
let x9 = { a: x8, b: x8, c: x8 };
let x10 = { a: x9, b: x9, c: x9 };
let x11 = { a: x10, b: x10, c: x10 };
let x12 = { a: x11, b: x11, c: x11 };
let x13 = { a: x12, b: x12, c: x12 };
export const y = x13;
/usr/bin/time -l tsc --declaration repro.ts

🙁 Actual behavior

Both compilers:

repro.ts(15,14): error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

Measured on macOS with /usr/bin/time -l:

compiler peak RSS wall
Go tsc 7.1.0-dev 2.48 GB 3.5 s
JS tsc 6.0.3 0.41 GB 0.6 s

In a limited environment, or with a larger repro, this will cause the process to OOM.

🙂 Expected behavior

Go tsc should report the same TS7056 error without using extra memory and being slower.

Additional information about the issue

Disclosure: This memory issue was found with a differential memory harness (Go tsc vs JS tsc 6.0.3) and AI assistance (Kimi K3). Verified by hand against TypeScript 7.1.0-dev (main) and TypeScript 6.0.3.

Activity

  1. yunasora commented on Aug 23, 2026

    @yunasora

    Hi, I’d like to work on this issue. I can reproduce the declaration emit performance regression and investigate the tsgo node builder/cache path, particularly the repeated AST cloning around DeepCloneNode. I’m happy to add a focused regression test and benchmark the fix against the current behavior. If this issue is still available, could you please assign it to me? I’ll share progress and discuss the approach before submitting a PR.

  2. jakebailey commented on Aug 24, 2026

    @jakebailey
    Member

    Did you have an actual project which hit this, or did you just find this with an LLM looking at the code?

  3. daniellockyer commented on Aug 24, 2026

    @daniellockyer
    ContributorAuthor

    Did you have an actual project which hit this, or did you just find this with an LLM looking at the code?

    This repro was found via an LLM but I'm trying to improve memory usage of tsc/tsgo in general. I've got a few other bugs incoming that I can directly link to a project (but cannot provide the source code for, so I need to find a minimal public repro anyway)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Possible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some cases

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions