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

10
26 comments

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

1

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

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

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

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

1

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

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

-2

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

 

 

3

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

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.

3

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

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

1

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

1

I and a couple of engineers I work with, recently faced the same issue. We use NX as well, and NX mental model https://nx.dev/more-concepts/applications-and-libraries#mental-model suggests that:

  • place 80% of your logic into the libs/ folder
  • and 20% into apps/

So we have many small libs, with own tsconfig files, etc. WebStorm is 'red' 90% of time not being able to analyze ts references, etc.. Probably WebStorm team can use this as an example: https://github.com/nrwl/nx-examples.

It's not an option to open every lib as own project, because it's not align with an idea of what we are trying to achieve with NX.

Sadly, I'm catching myself to use VSCode more and more and it's slowly becomes a way to go, for at least a monorepo project I'm working on.

2

Alex Di You seem to be doing it wrong. If you read in your own link: "Note, these libraries don’t necessarily need to be built separately, but are rather consumed and built by the application itself directly. Hence, nothing changes from a pure deployment point of view."

Libraries you build separately, should probably be treated as their own projects.

-1

d Nothing in my message tells, that I build them separately. Those libraries that I'm doing are exactly what articles states - are not built on their own and just consumed by application. However - whole NX setup still connects all that together by separate tsconfig, eslint, test config files.

 

If you would like to check how it works - you can generate you repo and create a couple of libraries, please note you need to use` bundler: none`, to make library not buildable on their own (https://nx.dev/packages/react/generators/library#bundler).

0

Hi,
I have the same problem Alex describes :

So we have many small libs, with own tsconfig files, etc. WebStorm is 'red' 90% of time not being able to analyze ts references, etc.. Probably WebStorm team can use this as an example: https://github.com/nrwl/nx-examples.

I have a lots of red, and difficulties to import classes from libs. I have to say I lose a lots of time with that problem, and I feel nervous to get so much red.

0

I have been thinking about this and I am wondering if the JB team can move the indexing to server side? This is how Google handles the indexing of its monorepo. Google have a IDE in browser (as a website) and the indexing happens on the server. It feels near-instantaneous. Of course this comes with a downside that JB will have to pull the code to their server, which might breach lot of company's policies but it could be an opt-in feature for open-source projects. Thoughts?

0

Did you try Fleet (https://www.jetbrains.com/fleet/)? Its architecture is distributed, separated into frontend, backend, workspace server, and file system watcher. See https://blog.jetbrains.com/blog/2021/11/29/welcome-to-fleet/#Fleetisdistributed

1

Elena Pogorelova I tried Fleet. It was not functioning properly and was even less usable than WebStorm. I'm currently on `2023.1.1 RC`.

0

disabling Inlay Hints did it for me, sad the performace on my os is so poor for this even if i have an i 7 and 16 gb ram

0

This is still happening by the way. We have a small monorepo with an api backend, a frontend and two libraries. The IDE has very poor performance, random crashes because of memory issues.

Intellij Ultimate edition (jan 25 build). 

Linux Ubuntu derivative (Kernel: 6.5.6-76060506-generic x86_64)
Laptop System: LENOVO product: 82JW v: Legion 5 15ACH6
Info: 8-core model: AMD Ryzen 7 5800H with Radeon Graphics bits: 64
16GB Memory

0

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

Hi, 

I've the same issue and seing the only response from the Jetbrains team is ‘Please try taking CPU snapshots when it runs slow’ i don't think they will solve this problem in near feature, so we are trying other products. The appeal for the Webstorm was to provide better developer experience for large projects and it seems it is failing miserably in monorepos.

0
There could be many causes for such issues and unfortunately there's no silver bullet for addressing them. We can hardly move forward without CPU snapshots.
0

Please sign in to leave a comment.