Replies: 9 comments 1 reply
-
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. |
Beta Was this translation helpful? Give feedback.
-
You can disable native diagnostics in rust-analyzer via 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 ( |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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.
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
So, to summarize, things you and others that working on bevy or similar projects with multi-workspace workflow want:
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. |
Beta Was this translation helpful? Give feedback.
-
@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.
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.
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
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.
Beta Was this translation helpful? Give feedback.
All reactions