IntelliJ node processes using a lot of CPU on TypeScript project. IntelliJ performance suffers.

Do you have Show project errors enabled in TypeScript tool window? If yes, does turning this option off make things any better?
js-language-service is just a wrapper around tsserver provided by Microsoft... Can be related to watching the project dir recursively (https://github.com/Microsoft/TypeScript/issues/26968, https://github.com/Microsoft/vscode/issues/51139). What TypeScript version do you use?

Thanks for the quick reply... Will give the above a try now... My yarn.lock states the following for typescript version:

3.4.5

It still seems to be getting to 100% CPU quite regularly after turning off "Show project errors"

Any other suggestions?

No, sorry:( If disabling "Show project errors" doesn't help, it must be the issue on tsserver end that can't be fixed by JB:(

At least you've narrowed it down for me then :) I didn't know what that was wrapping before.

I have a similar problem, using IntelliJ 2019.2.3. Strangely, I don't seem to get the same issues using VSCode!

I have tried EAP versions of IntelliJ (latest as of date of comment) and rolled back TypeScript from 3.6 to 3.5/3.3 with no luck.

I can arrange access to the (currently private, but soon to be open sourced) repo. 

It seems to be an eslint issue in my case

Same thing for PhpStorm 2019.3 EAP, using for project with TypeScript and Styled Components. Node process just burn out my CPU (i7-8665U). Any suggestions?

Must be the issue with either the tsserver itself or one of its plugins...

I have the feeling as it would start if I add new packages to my module via yarn on the cmdline. 

My usecase is like this:

- Open WS
- Open iTerm
- yarn start (runs Webpack dev server)
- recognize I need a package from npmjs
- Ctrl+C in iTerm
- Add new package via yarn
- yarn start 

This seems to push node and my cpu to it's limits

Its even worse with 2020.1 EAP

----

WebStorm 2019.3.2
Build #WS-193.6015.40, built on January 21, 2020
Runtime version: 11.0.5+10-b520.30 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.6
GC: ParNew, ConcurrentMarkSweep
Memory: 1981M
Cores: 8
Registry: wolf.the.problem.solver=false, documentation.show.toolbar=true, jest.test.tree.use.jasmine.reporter=false, ide.suppress.double.click.handler=true, js.debugger.webconsole=false
Non-Bundled Plugins: Quick Notes, com.dubreuia, com.flageolett.nodeconfig, com.paperetto.dash, com.tobszarny.activetabhighlighter.plugin.id, ru.adelf.idea.dotenv

For me it was also eslint causing high cpu load. 6.8.0 was a problem, 6.7.2 seems to be ok.

Roland Heim can you elaborate how you turned off eslint? I am also seeing very high CPU usage in intellij for the node typescript language service (which doesn't exhibit in vscode).  

I am having the same issue. Unfortunately, disabling eslint didn't help.

Having the same issue. No problem when doing the same in VSCode, so can't event submit an issue to TypeScript. What I'm doing: just editing https://github.com/aleksei-berezkin/fluent-streams/blob/master/src/impl/indexImpl.str.test.ts . How can I help you locating the problem? I can take TS Server logs or profile TS Server if you give me a hint how to do it. (TypeScript -> Console is not TS Server log)

IDEA is the newest, node and TS are the newest

>I can take TS Server logs or profile TS Server if you give me a hint how to do it.

You can try the following:

• in Help | Find action..., type registry...
• open Registry..., locate typescript.service.node.arguments key there (you can start typing property name to navigate to it)
• add --prof option there and reopen the project.
  This will enable NodeJS profiling and create an isolate-**-v8.log file in the service working directory. The log file can then be analyzed by using WebStorm's profiler or the NodeJS --prof-process option described in the article.

Hi Elena, thanks for your detailed instructions. I've taken the profile, it's huge (40M), here's the link https://yadi.sk/d/K7UOX4nwL2rdXw

We can see from it that, after some work, processImmediate() from timers.js is called many times, and it takes about 20s which is like what I observe: after editing CPU gets 100% for exact this time.

Hope this helps fixing the problem! So we may happily return to WebStorm from other editors.

Alexey Berezkin is there then anything we can do to make webstorm more efficient?

Or did you add an optimization for future version?

thanks

@... Nope I didn't optimize anything. I have just looked into a profile and found out that there's some very long computation in TS Server, perhaps busy-waiting, perhaps triggered by WebStorm (IDEA). I'm not sure I can tell what's the reason, I just can observe it in IDEA (and cannot in VS Code).

UPD I also collected TS Service logs according to https://intellij-support.jetbrains.com/hc/en-us/requests/2873872?page=1 but they seem like not revealing anything interesting

I profiled and debugged tsserver yet more, and compared it to VS Code, and found out the problem is likely in the TS. The semanticDiagnosticsSync is embarrassingly slow; and the larger is file the slower is method, and the time seems to grow non-linearly. I made several races with VS Code, and the results are actually +- same. So it seems WebStorm team can't do a lot :( Perhaps help submitting an issue or pointing to an existing one?

For those who encounters this issue later: TypeScript is slow, and its performance degrades non-linearly with file growth. The only way to get it fast is to keep files small.

Alexey Berezkin thank you so much for investigating this. In a previous comment you mentioned that you could not reproduce the issue on vscode, but on the last one I understand that both suffer the same issue. Did I get it right?

Can you advise what you mean by small files? 200 lines, 50 lines?

I'd be so grateful if you could report the issue to the typescript team

cheers! 

@... You are welcome. Thanks also for the detailed instructions.

In VSCode the process running tsserver is called not “node” but “Code Helper (Renderer)” which confused me — I thought it's some Electron internals. Second, VSCode itself consumes less CPU than WS, so the effect (fan noise) is less noticeable by naked ear. However, accurate measures reveal tsserver spawn by VSCode and by WS consume the same CPU.

About limitations, personally I try to keep files <400 lines and <20 imports. Also, I wrote a post of this story. https://dev.to/alekseiberezkin/typescript-is-slow-what-can-we-do-about-it-30hm

There's an open issue on TS GitHub which unfortunately was lacking an example. So I attached one. Hope the team now has everything needed to analyze the problem. https://github.com/microsoft/TypeScript/issues/40138#issuecomment-701375173

Adding node_modules to my tsconfig exclusion list fixed this for me.
Although this had never been an issue for me before, and the project worked fine in VS code without the exclusion.

Edit: Actually now it's back to using 200% CPU again. 
Dunno how to fix it, but I think it's somehow related to node modules being scanned, my actual app code is pretty small.

I'm having similar issue with JS language service. In my case TS compiler is ok, but for some strange reasons IDEA is running not one but actually five instances of ESLint. Considering each of them consumes about 500MB of RAM, I'm forced to restart the project very often.

Can report the same problem. Noticed `node` process taking almost 100% CPU and `ps` gives me this:

```

501 28601 27952 0 1:52PM ?? 17:46.22 /usr/local/bin/node /Users/Dzmitry_Kankalovich/Library/Application Support/JetBrains/Toolbox/apps/IDEA-U/ch-0/203.7148.57/IntelliJ IDEA.app/Contents/plugins/JavaScriptLanguage/jsLanguageServicesImpl/js-language-service.js -id=1616590325663 -debug-name=typescript

```

Elena Pogorelova
> add --prof option there and reopen the project.This will enable NodeJS profiling and create an isolate-**-v8.log file in the service working directory. The log file can then be analyzed by using WebStorm's profiler or the NodeJS --prof-process option described in the article.

Using WebStorm profiler just totally hangs WebStorm in the `Recording indexes` phase. Nice!