Regression performance compiling types in version 5.4.2

[georgekaran]

🔎 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

[Andarist]

Could u share a repro case of this problem?

[fatcerberus]

The number of instantiations went up over a hundredfold 😱

[jakebailey]

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

[georgekaran]

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.

8d1fa44 is the first bad commit
commit 8d1fa44
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]

Could u share a repro case of this problem?

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

[fatcerberus]

@Andarist It’s one of your PRs: #54813

[Andarist]

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

[georgekaran]

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

Sure thing, I will work on creating a reproducible for this issue. It may take a while as our codebase is quite large 😞

[sandersn]

I sent a PR to revert the change, but it's likely that the underlying bug was unrelated, and exposed by this change. @weswigham believes it is possible to construct a failure that relies exclusively on functions, not on constructors. Long-term, we should isolate and fix the underlying bug and re-apply this change.

[sandersn]

@georgekaran would one of the TS team at Microsoft be able to sign an NDA to get access to your code? Then we could isolate the problem and produce a repro that's not linked to your code.

[jakebailey]

Even if you can't share the code for now, can you try running tsc via https://www.npmjs.com/package/pprof-it? The profile won't include any code, and if you enable PPROF_SANITIZE=true, shouldn't include any paths or other info from your machine. (But I would verify the output file.)