Regression performance compiling types in version 5.4.2 about typescript HOT 18 OPEN

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

from typescript.

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

from typescript.

The number of instantiations went up over a hundredfold 😱

from typescript.

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 [email protected]
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 <[email protected]>

from typescript.

@jakebailey Looks like you're right about what I'm seeing being a different bug. Commit 8d1fa44 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.

from typescript.

Could u share a repro case of this problem?

from typescript.

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.

from typescript.

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

from typescript.

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 😞

from typescript.

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.

from typescript.

@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.

from typescript.

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.)

from typescript.

I just want to chime in and say that I think I'm encountering the same issue, however updating to 5.4.3 hasn't fixed the problem. I'm still seeing the error:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

I'm actually seeing this when running ESLint, but I've been able to track it down to something related to the TypeScript config that's being used. Using the same config that worked fine with TS 5.3 will cause the OOM errors in TS 5.4. Changing that config to exclude certain directories (and hence reducing the overall size of the project) avoids the OOM errors.

Unfortunately, I also cannot share a repro for the same reasons (closed-source, company project, etc), and there's next to no chance of an NDA being allowed. I'll see what I can do to get a simpler reproduction though.

from typescript.

I would definitely recommend using every-ts and linking it in to bisect, if it's reproducible. But I would doubt that your issue is related; typically bugs like this aren't, but a bisect would say .

from typescript.

Sorry, I commented on a couple of other old issues before I read some comments about trying to group things by at least versions (in my defense, there's a lot of OOM issues open 😅)

--
I'm running into the same on GitHub Actions Runner (ubuntu-latest) but not on local (M1 Pro).
Please ask for more info that might be helpful and I'll examine if there's something I'm at liberty to share.

Some basic relative info:
Next App, large-ish project.
Running into this error on [email protected] but working on [email protected] in Github Actions, always works on local.
using "zod": "^3.20.3"(seemed relative to another OOM issue I found)

from typescript.

Sorry, I commented on a couple of other old issues before I read some comments about trying to group things by at least versions (in my defense, there's a lot of OOM issues open 😅)

Not sure what you mean; we want new issues for different OOMs because they're very likely unrelated, unless you've bisected the problem to the same thing as this particular issue.

from typescript.

unless you've bisected the problem to the same thing as this particular issue.

Right, gotcha, well that's kinda difficult in my case as it's only happening on GH Actions :/
What would be the best way to try and spot it?
Still testing manually on local (with every-ts) and checking for a memory spike?
And hoping that it's platform (Mac vs. Ubuntu) independent?

(thx for the quick reply btw!)

from typescript.

--extendedDiagnostics should show memory usage, or you could artificially lower the max memory with Node's max-old-space-size. That or provide a repro.

from typescript.