Poor performance with mid-size monorepo

Hi,

I am long time user of WebStorm and love it so much.
At the current company we're progressively moving to mono-repo which makes is great in terms of team development, but for some reasons, WebStorm is really slow for me in this project.
What I mean by slow?

e.g. double-shift brings results in seconds after typing, while normally they come up immediately in different projects. I use double-shift all the time, so it makes my really tired by its lack of responsiveness. 

It is NX + TypeScript + ESLint project. 

I am wondering what can be done to improve it? 

One thing I've noticed is that it often indexes some dist folders which are hard to exclude as they are often somewhere deep etc (why WebStorm exclusions cannot use similar format to gitignore so could autoignore every dist?)

14 comments
Comment actions Permalink

Try adding dist to Ignore files and folders list in Settings | Editor | File Types - does it make things any better?

1
Comment actions Permalink

Unfortunately it does not help at all, even more (as mentioned in the YT ticket) it was breaking some autocompletion. 

1
Comment actions Permalink
Please could you clarify what YT ticket you refer to?
0
Comment actions Permalink

https://youtrack.jetbrains.com/issue/WEB-57667/WebStorm-does-not-see-exports-of-rpm-package
Any other suggestions for fixes the crazy bad performance?

I tried to invalidate caches, reinstall node modules etc but nothing help.

 

0
Comment actions Permalink

Did you try marking all build target folders 'excluded' manually, with Mark directory as right-click menu action?

0
Comment actions Permalink

Hi, yes. It does not help at all. Double-shift provides suggestions few seconds after typing.

It hurts DX so much.

Anything you can do to help?

If it matters, we use pnpm to install dependencies.

1
Comment actions Permalink

please try taking CPU snapshots (https://intellij-support.jetbrains.com/hc/en-us/articles/207241235-Reporting-performance-problems) when it runs slow and submit them along with the logs (Help | Collect Logs and Diagnostic Data) within a youtrack ticket

-1
Comment actions Permalink

Our company recently moved to a Monorepo using NX (also about mid-size) and Webstorm is tremendously slow. Our entire team had to switch to another editor. 

Code completion was extremely slow, to the point of being unusable. 

I've tried the following:
- Increasing WebStorm memory allocation
- Invalidating Caches and restarting
- Adding all dist and tmp folders to ignore
- Turning off all extra plugins
- Disabling Github Co-pilot

Unfortunately none of the above seemed to help.

 

Edit:

For reference the machine i use:

2022 MacBook Pro 14"

16 GB memory

1TB storage

 

 

0
Comment actions Permalink

please try taking CPU snapshots when it runs slow

1) Help > Diagnostic tools > Start CPU usage profiling
2) perform the actions which are causing high CPU usage, try to reproduce the performance problem several times while the snapshot
3) Help > Diagnostic tools > Stop CPU usage profiling

and submit them along with the logs (Help | Collect Logs and Diagnostic Data) within a youtrack ticket 

0
Comment actions Permalink

Maybe you guys from Jetbrains can try yourself. My whole team experiences this and actually the whole company I bet. We pay you money for an IDE. I expect a pro-active approach for making sure everything works normally, not automated robo-replies. Monorepo's are the future. If you don't fix this you're going to loose your customers to VSCode.

1
Comment actions Permalink

EDIT:

Okay! Nevermind... it started happening again after about 20mins. :( 

EDIT 2: 
Edited the text to be more clear. 

Update from my side:
I disabled all Inlay Hints and ML Code assitance

  • Editor > Inlay Hints (unchecked everything)
  • Editor > General > Code Completion - Disabled Sort completion suggestions based on machine learning. 

This did improve the experience, but as edit 1 mentions, it become slow after a short time. Also, as Paalthingbo pointed out, this is not ideal and defeats the point of paying for a IDE over a text editor. 

0
Comment actions Permalink

@Dewaldifels That's bad advice. Those are some of the reasons for using an IDE in the first place.

1
Comment actions Permalink

Appreciate the feedback, but it wasn't advice. Just letting you know what I'm trying :)

1

Please sign in to leave a comment.