Performance issues when working with multiple projects at the same time

[IceSentry]

My workflow generally involves having multiple (4-6) large projects opened at the same time. Part of the reason why I have so many workspaces opened at the same time is because how long it takes for RA to start when I open those projects but keeping multiple projects opened is also very resource hungry when it's using multiple gb per projects. On my windows machine I'm seeing between 2.5gb and 5gb per projects.

Here's a bit more detail on my workflow:

• I'm a very active bevy contributor so I very frequently reference it, edit the code, review PRs, etc. I don't need it always opened, but since it's such a large codebase it can take over a minute to reach a state where I can actually navigate around the code using RA. It's big enough that I've had RA crash a couple of times. (sidenote but bevy in general is a big RA stress test, it's also a rustc stress test to be fair)
  • I generally open the entire workspace because I frequently need to touch multiple crates
  • I also often need to reference many parts of the codebase without needing to edit the code or care about any errors
• I also work full time on a massive codebase that is similar in scale and structure to bevy and is built on top of bevy.
  • When I work on that codebase it's sometimes easier to only open the crates I need instead of the entire workspace but I only do that because opening the entire workspace is too slow and uses too much memory. I would much prefer if I could open it completely. I know most of my coworkers also have this issue. Some of them have decided to simply not use RA because it was getting too in the way. I often have 2-3 of those crates opened at once, but I generally only edit one and use the others as reference only.
  • I also end up referencing the bevy codebase quite a lot for work, but since we are on an older version of bevy it means I need a separate instance of RA running on that older bevy workspace

Essentially, I frequently open multiple projects to be able to reference the code and I like using RA to navigate the codebase but I generally don't care about anything else related to editing code that RA offers. I would like to be able to quickly open/close those workspaces instead of keeping them open because but since RA takes so long to start it's very annoying to work like that.

None of this is related to a specific RA version, I've been working like this for years and had these issues for years but it was recently suggested to me that I should let the RA team know that this is a problem.

[IceSentry]

After discussing this a bit more in the bevy discord a few more people have voiced that they would also like a navigation only mode for RA. We often only need to navigate the code to reference stuff and we don't care about errors in the file.

[Veykril]

We often only need to navigate the code to reference stuff and we don't care about errors in the file.

You can disable native diagnostics in rust-analyzer via rust-analyzer.diagnostics.enable (in VSCode at least).

Aside from that I am not sure what the ask here is though. We are aware that rust-analyzer is resource hungry, we are trying to improve that but its difficult and a slow moving effort. That is just unfortunately one of the downsides of Rust, it is heavy to analyze semantically. Bevy being such an incredibly heavy project obviously doesn't help in that regard either (especially given its type system and macro use as well).

The best you can do here is to disable the majority of features I suppose, that is disable diagnostics, semantic highlighting, inlay hints etc as all of those incur file wide analysis. Additionally to reduce upfront memory usage you can disable cache priming (rust-analyzer.primeCaches.enable iirc) which will make initial IDE requests slower but prevents r-a from doing a lot of upfront cache population (including symbol / import caches which you don't want here in a read only scenario).

[IceSentry]

So this isn't exactly a feature request. This is more about highlighting a workflow that doesn't work well with the current way things work. The biggest issue in this workflow is that RA is not designed to be opened and closed often so I am forced to keep a ton of instances opened which has the side effect of using too much ram. Having more things cached between runs so opening a workspace doesn't take minutes before RA is responsive would be very appreciated.

As for disabling features, I can't really do that trivially, I still use all of these features when I'm editing code, but when I'm not editing code those features are not needed. That's why I mentioned a navigation "mode", being able to default RA to navigation only and then only start the editing features when I actually need them would be immensely helpful (assuming that means faster startup of course). There might be a way to configure neovim to do that because it gives a lot of control over how the lsp is used, but I don't see how vscode users or users of other editors that aren't as configurable as neovim would be able to do that without something more built-in. With that said, I will try experimenting with disabling things by default in my neovim setup and see if that helps my workflow or not. I didn't realize a lot of those features could be disabled.

Also, to be clear, for me the issue is a lot more about startup time on large projects than resource consumption. The high RAM usage is not ideal, but I can deal with it because I have a ton of RAM and can always buy more, but the startup time is still a bottleneck even on what is essentially the fastest consumer level cpus currently (apple M4 max and a ryzen 9950x).

The reason I made this issue is more about giving feedback on how RA is used in practice and pointing out where the pain points are. I know in bevy we appreciate this kind of user feedback because it helps guide development. I made this issue at the suggestion of @workingjubilee after talking about this in the bevy discord. I'm not sure if there was maybe a better place I should have posted that kind of feedback.

[ChayimFriedman2]

We know startup speed is an issue, and we plan to serialize some info to disk to allow for faster startup. This is unblocked now that we migrated to the new Salsa, but people are apparently working on other things currently.

As for resource usage, there isn't really anything we can do. If you open multiple projects, r-a has more code to analyze, so of course it will consume more resources.

I'm not sure what you want if you don't want to disable the features. In VSCode you can have different settings per profile - perhaps you can use that? But I don't see how r-a can support this better.

About the user feedback, it's just that we get a lot of complaints (in existing issues and once a while in new issues) that r-a is resource hungry, that another one doesn't add something. And honestly, personally, I'm just tired of hearing that more and more.

[IceSentry]

We know startup speed is an issue

That's not something I knew the RA team was working on. I always assumed RA was designed to be opened once and stay open and that's why it was slow to startup and that it was intentionally the direction the RA team was going. The last blog post is from a couple of years ago so it's not necessarily obvious as an average user to know what you are working towards. I simply assumed my workflow was maybe a bit less common and is not the kind of workflow the RA team is considering when designing new features. Maybe I should have spent some time in the zulip chat instead of making an issue on github, but I'm happy to hear my assumptions were wrong about the current priorities.

I'm not sure what you want if you don't want to disable the features

It's not that I don't want to disable features, I just don't want to disable them in every context. That's why I described my workflow and explained that I often, but not always don't need features related to editing/linting code and that's the part that AFAIK isn't really easy to do right now. I don't really know anything about how RA works so I can't really ask for anything specific other than saying I often, but not always, use it in a context where not all features are required and being able to support this seamlessly would help this kind of workflow. I just don't know enough about RA to suggest how that could be done.

A potential solution could be something like a "navigation mode" that would only contain features related to navigating a codebase then have an "editing mode" that would allow all features and would essentially be what we have today. The default setup would be to always use "editing mode" but advanced users could configure it so "navigation mode" is the default mode and then be able to toggle editing mode based on some kind of user input (command palette, key bind, etc.). But like I said, I don't know enough about RA to know if that's possible or even makes sense to implement. I'm trying to implement something like this in my neovim config but having this a first party concept would make it much easier.

Also, for the resource usage, it's really not a big deal for me. I wasn't trying to beat a dead horse by mentioning it, it's not ideal, but it's not at all the main issue for me. It was just a side note to give more context.

[ChayimFriedman2]

Given that we already provides all the knobs to tweak r-a behavior and all it requires is changing a setting, you can create a command that does that yourself. I don't think r-a is going to provide such command, since the things you described you don't want (semantic highlighting, inlay hints etc.) except diagnostics are also useful for navigation.

[ShoyuVanilla]

So, to summarize, things you and others that working on bevy or similar projects with multi-workspace workflow want:

• General performance improvement: This has been heavily worked on and you can see what has been done and what has not yet in A Plan for Making Rust Analyzer Faster #17491. Salsa migration was a big step for many things and this talk in RustWeek expalins about it and we currently working on improving both our usages of salsa in rust-analyzer and salsa itself. Another big step is a migration to next-gen trait solver - currently, rust-analyzer's trait solver is chalk, which has been doing its job greatly for years, but as it was an experimental prototype made before rustc's next-gen solver, it has some problems like performance issues and failures on solving some goals, which results in most of our type inference errors. Migration to next-gen solver has been our "flagship goal" with salsa migration, though virtually a single person, Jack Huey - rust type team lead is working on it but we care a lot about it like removing obstacles that blocking that migration.
• Faster startup time: There has been some improvements to this but real big changer would be persisting cache on filesystem as you said, and this is very likely to done in salsa. But we and salsa still have other imminent issues to solve in salsa, so this might not be done very soon.
• Mitigating resource hunger: This is heavily related to salsa, again and you can see what being done with the talk I've mentioned above. There are still some opportunities to improve this but most low-hanging fruits were harvested, so there might be no big improvements on this for a while.
• Switching between "tourist" and "engagement" mode: I think this wasn't what we had in mind directly. As other people said, I think this should/could be done by changing settings, but repeatedly managing multiple options is quite irritating and some options need restarting rust-analyzer, probably what you don't want. Making more options free of restarting might be great and I'm interested in working on it. And for managing multiple options at once, like switching between some presets, would be nice and implementing this on rust-analyzer's vs-code client side sounds reasonable to me, as it is our only "first party" client and doing some scripting on vs-code is not so trivial to users on contrary to other editors like neovim, as you said. And I'm interested in implementing that too, but other people might not want that.

I think that your intention is just to arose rust-analyzer team's attention to some non-regular workflows like yours and problems in current rust-analyzer for that workflows. But there are many things in rust-analyzer that should be worked on and as it is not a kind of OSS project that maintained by a team of full-time employees from a big tech, some of them might be slow to be improved.

[IceSentry]

@ShoyuVanilla Thank you for the summary and yes that does cover everything! I think your terminology of "tourist" vs "engagement" does represent pretty well what I'm talking about.

I think that your intention is just to arose rust-analyzer team's attention to some non-regular workflows like yours and problems in current rust-analyzer for that workflows. But there are many things in rust-analyzer that should be worked on and as it is not a kind of OSS project that maintained by a team of full-time employees from a big tech, some of them might be slow to be improved.

Yes, I'm actively trying to not sound like I am demanding anything and I really don't want to diminish all the work that has been done and is being done. I'm very aware how open source work often ends up being done based on what people want to work on and you can't really control that direction. I'm coming into this with the perspective that with bevy I have ended up many times making PRs that I would have otherwise not been interested in after seeing a user report doing something that we never considered before.

@ChayimFriedman2

I don't think r-a is going to provide such command, since the things you described you don't want (semantic highlighting, inlay hints etc.) except diagnostics are also useful for navigation.

Yes, I agree semantic highlighting is useful for navigation which is why I never said I don't want it :)

Obviously if a feature like that ever materialized there would need to be a discussion about which features only make sense for editing or navigation. Also, maybe some features could take shortcuts if they know they are used in a navigation mode. I don't know enough about how RA works to know all the options. That's why I wanted to have this discussion. To help figure out potential solutions. Maybe someone will see this and think of a neat way to make this workflow nicer or maybe it will never happen and that's completely okay too. I don't know what the RA team knows or doesn't know so I decided I might as well bring it up with the people that know this better than me.

[Veykril]

Also to note, a navigation mode wouldn't make anything faster. Editing capabilities/features basically do not affect anything in r-a perf wise / start up wise (exception being the import index we populate on start which is used by refactors/completions only).

Either way it's clear now what you want most (and a lot of us to do too!) is persistent caching, but as was said, this needs to be implemented in salsa (and from what I recall still needs quite a bit of work on the salsa side unfortunately).

I'll turn this into a discussion, given its not a direct issue.