TypeScript: Regression performance compiling types in version 5.4.2

🔎 Search Terms

“regression”, “5.4.2”, “performance”

🕗 Version & Regression Information

This changed between versions 5.3.3 and 5.4.2

⏯ Playground Link

No response

💻 Code

Extended diagnostics in version 5.4.2

Files:                          4294
Lines of Library:              40640
Lines of Definitions:         180807
Lines of TypeScript:          430513
Lines of JavaScript:               0
Lines of JSON:                     0
Lines of Other:                    0
Identifiers:                  591567
Symbols:                     1232510
Types:                       4677381
Instantiations:            395496734
Memory used:                2330550K
Assignability cache size:    3974893
Identity cache size:           14482
Subtype cache size:            37794
Strict subtype cache size:      9374
I/O Read time:                 0.70s
Parse time:                    0.96s
ResolveModule time:            0.58s
ResolveTypeReference time:     0.01s
ResolveLibrary time:           0.01s
Program time:                  2.51s
Bind time:                     0.62s
Check time:                  367.45s
printTime time:                0.00s
Emit time:                     0.00s
Total time:                  370.58s

Extended diagnostics in version 5.3.3

Files:                         4290
Lines of Library:             40241
Lines of Definitions:        180807
Lines of TypeScript:         430513
Lines of JavaScript:              0
Lines of JSON:                    0
Lines of Other:                   0
Identifiers:                 591320
Symbols:                    1234773
Types:                       699200
Instantiations:             2247099
Memory used:               1308962K
Assignability cache size:    223823
Identity cache size:          14479
Subtype cache size:           28353
Strict subtype cache size:     9128
I/O Read time:                0.73s
Parse time:                   1.11s
ResolveModule time:           0.44s
ResolveTypeReference time:    0.01s
ResolveLibrary time:          0.02s
Program time:                 2.60s
Bind time:                    0.76s
Check time:                  13.75s
printTime time:               0.00s
Emit time:                    0.00s
Total time:                  17.11s

🙁 Actual behavior

The type validation using tsc --noEmit increase more than 20 times using the version 5.4.2 comparing with the version 5.3.3.

In the CI is always hitting the heap memory limit:

🙂 Expected behavior

I expected the compilation to be equivalent in both versions, but it was more than 20 times slower.

Additional information about the issue

No response

About this issue

Original URL
State: open
Created 4 months ago
Reactions: 1
Comments: 18 (9 by maintainers)

Most upvoted comments

Unfortunately, I cannot share a repro for this problem as this is an internal closed-source project from my company.

Understandably, u might not be able to share it as-is. To investigate this I’d need some kind of a repro case though - I can’t chase a wild goose

Andarist on Mar 11, 2024

If you can reproduce this consistently, consider bisecting using https://www.npmjs.com/package/every-ts.

jakebailey on Mar 9, 2024

@jakebailey Looks like you’re right about what I’m seeing being a different bug. Commit 8d1fa440dd5ad547e836abcca45ccc94e81f1fe2 doesn’t exhibit the behavior that I’m seeing.

every-ts is awesome by the way! ❤️

I had a bit of trouble using every-ts bisect to pinpoint when the bug that I’m seeing was introduced. Bisecting 5.3.3 and 5.4.2 led me to the problem commit being one that only changed files in the .github/ folder 😆. I have a feeling that might be because the bug was introduced at some point, then fixed or reverted, then introduced again. Edit: I must have made a mistake on multiple bisect runs, because I just tried again and ended up with the correct commit that’s causing my error. 🤦‍♂️

I was able to successfully use every-ts bisect to pinpoint the commit where the bug I’m seeing was introduced. 🎉 I’ll create a new issue about it.

Edit: #58011 is the new issue.

reduckted on Mar 31, 2024

If you can reproduce this consistently, consider bisecting using https://www.npmjs.com/package/every-ts.

I was able to pinpoint the exact commit which the performance problem was started.

8d1fa440dd5ad547e836abcca45ccc94e81f1fe2 is the first bad commit commit 8d1fa440dd5ad547e836abcca45ccc94e81f1fe2 Author: Mateusz Burzyński mateuszburzynski@gmail.com Date: Thu Nov 30 20:24:04 2023 +0100

Defer processing of nested generic calls that return constructor types (#54813)

Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>

georgekaran on Mar 11, 2024

The number of instantiations went up over a hundredfold 😱

fatcerberus on Mar 9, 2024