Solution style tsconfig - TS Server is slow to respond when having a large number of references #39144
Comments
RyanCavanaugh
added
the
Needs Investigation
|
I'm having a similar issue with a big monorepo, multiple When I do "go to declaration", or ctrl+click on an identifier from a different file, in a JS or TS file, CPU spiked to 100%, RAM is getting out of control, and TypeScript server logs is full with: Sometimes it stops and go back to normal, but in most cases it's just shows TS Version is I tried to disable |
…low users to disable loading large solutions Fixes #39144
sheetalkamat
added
Fix Available
…low users to disable loading large solutions Fixes #39144
…low users to disable loading large solutions Fixes #39144
|
Also running into this but our solution references isn't that large - like 6-7 of them. Every time code changes it takes a good 10-15 seconds before typescript types come back - vscode just shows loading for that period. Didn't have this issue before moving to incremental builds. Most of our references are like 5-6 files with a couple hundred lines. The entire project before could build in around 8-12 seconds and now it takes 20+ seconds on every edit instead. |
|
@bradennapier Please open a separate issue with repro steps and tsserver log so we can look at that one. This one is specifically to ensure that we provide a way to opt out of referenced project loading if your project is large so you want to skip that part. |
…n has some of its own files and project references (#39613) * Use disableReferencedProjectLoad to stop loading child projects to allow users to disable loading large solutions Fixes #39144 * Handle indirect references * Support loading of child project if found project is not pure solution has some of its own files and project references Fixes #38605 * Fix grammar
|
@sheetalkamat thanks - i think I figured out why it is happening and opened / commented on that instead. Thanks. |
|
For reference, anyone who runs into this should be able to set the |
|
@DanielRosenwasser so definitely running into this now that I am testing again - and if i add that new value to every single tsconfig in my project that seems to fix it -- but it isn't directly clear what I am losing by setting that to true. Do I lose a bunch of language features? What is most annoying I think, is that the type returns in about 1 second then moves to loading which takes 1-2 minutes just to tell me the same type again without this feature on. If I do not have a top level |
|
That's part of the tradeoff - if you have that setting on, TypeScript will avoid loading up entire projects for each set of references. I believe that means things like find-all-references within your project might not give results full results for projects that you depend on.
I'm not exactly sure what you mean here, but it might be expected given that for certain operations, the project needs to immediately load to answer a question. |
|
Essentially it loads properly and gives me the typing I want then it takes a minute after that initial load before I can see it again after the initial load. I cut it off too early, but when I move my cursor off then back on - it basically saying Diagnostics does show it returns immediately and gives me the desired result then this request takes a long time: Then similar take another 30 seconds or so for references so its just over 60 seconds in all -- which makes sense since that is how long a full compile takes (even though I have dist compiled with all the tsbuildinfo files up to date) |
TypeScript Version: 3.9.5
Search Terms:
solution style
ts server solution
Use Cases
In Angular CLI version 10, we opted to use solution style tsconfig's. It was however brought to our attention that when creating a monorepo style project with a lot of project references, TS server takes a lot of time to response.
Examples
In following reproduction https://github.com/alan-agius4/solution-style-tsconfig-perf, we have a monorepo with 100 projects, each of which add 2 tsconfigs in the root level solution style tsconfig references. https://github.com/alan-agius4/solution-style-tsconfig-perf/blob/master/tsconfig.json
Having a solution style tsconfig that references a lot of tsconfig's results in slowdowns when opening a file in the IDE.
For example when opening
projects/lib100/src/lib/lib100.component.tsin the above reproduction we get the following logs. Where we see that forupdateOpenresponse it took21895ms, similarly forprojectInfo,getSupportedCodeFixesetc..Global level solutions tsconfig
Other considerations
While it is expected that having a lot of projects reference result in a slow-down. This seems to be a bit excessive. Maybe the logic to determine which project a file belongs to can be improved?.
With this in mind, we are considering to change the approach we took and create "mini" solution style tsconfig, where instead of having a global/workspace level solution tsconfig, we add one in each project which will contain 2 project references.
Adding a solution tsconfig at the project level, ie https://github.com/alan-agius4/solution-style-tsconfig-perf/blob/master/projects/lib100/tsconfig.json.bak and perform the same task. We get a totally different result. We see that for
updateOpenresponse it took1203ms, similarly forprojectInfo,getSupportedCodeFixesetc..Project level solution style tsconfig
Other information
This effects users outside of Google, as internally solution style tsconfig are not in use.
//cc @mprobst, @kyliau & @IgorMinar
Related Issues: None that I am aware of.
The text was updated successfully, but these errors were encountered: