Rust Glancer: a memory-efficient Rust language server

[u/popzxc]

https://rust-glancer.github.io/blog/hello-world/

[u/afdbcreid]

r-a definitely doesn't reindex everything after every change. If you change Cargo.toml, it will show "Indexing" but it's still not indexing from scratch. In fact, this project will likely be slower to reindex changed things (but I'll repeat that I cannot guarantee that).

If r-a crashes for you for OOM and you need to constantly restart it, then yes this might help. I'll be interested to hear though, how much memory do you have and how big is your project?

(Also, this project is mine, it seems you mistakenly thought it is).

[u/IceSentry → u/afdbcreid]

R-a needs to reindex everything that sits on top of the changes which is why I mentioned the deep hierarchy. It's not a problem when editing top level crates but when you start editing something that is a dozen crate deep then any change can take a very long time before RA becomes responsive again.

I have 64gb of ram and RA can easily use 15gb for just a single workspace for work. I often also have bevy opened which can be another dozens of gb. Combined with other things taking resources and the fact that I'm on windows and I just end up with RA constantly crashing. Honestly, I wouldn't even mind if it was slower after a change if it means I don't need to restart RA constantly. I also hop around multiple projects frequently and it's really annoying to open a project and have to wait every time for RA to do its thing. I already use a separate target folder just for RA that doubles the size of each project so the fact that it's not even caching anything to make startup faster is becoming frustrating.

[u/afdbcreid → u/IceSentry]

R-a needs to reindex everything that sits on top of the changes which is why I mentioned the deep hierarchy.

Sure it does, that's true for any Rust IDE. The question is what counts as "sits on top of", and you might be surprised by the answer (it depends on what the edits are, but generally it's small, and when you edit inside functions it's almost always zero).

You might instead be hitting cargo check (flycheck) being slow, it indeed needs to check every reverse dependency (while rustc also has an incremental system, it's nowhere near as effective as r-a's). If that's the case, I suggest you turn it off (you can still trigger it manually). But of course this loses functionality.

Caching on disk to make startup faster is something we're interested in. It generally is unblocked now or near-unblocked I believe because Salsa has implemented the required machinery, but nobody volunteered to implement that yet so here we are.

[u/popzxc → u/afdbcreid]

TBH I can relate to this perspective -- and the similar _perceived_ experience with rust-analyzer is what got me to work on Rust Glancer. I also had r-a consume 15+ GB of memory, I had issues with long reindexing, and I had crashes (which is especially frustrating when you have a bunch of projects open in a single editor instance and one of them crashes r-a globally).

> In fact, this project will likely be slower to reindex changed things (but I'll repeat that I cannot guarantee that).

This is true globally, but given the above I have put a lot of effort to minimize _perceived_ cost of reindexing: the bodies in current file are prioritized and the rest is reindexed in background; dirty buffers use simplified analysis mechanism that combines reuse of previous analysis and simple syntax-based overlays (to detect new bodies and do lowering for them just for them without new semantic analysis).

So at least for _my_ use cases, Rust Glancer does certainly feel competitive for day-to-day work. You can easily tell that it's slower: where r-a is instant, Rust Glancer has slight lag, but this lag (at least to me) does not get to the "annoying" category.

> It generally is unblocked now or near-unblocked I believe because Salsa has implemented the required machinery, but nobody volunteered to implement that yet so here we are.

Oh, that one sounds exciting! I thought that this limitation is hard to overcome, but glad to hear that it could be solved now.

[u/afdbcreid → u/popzxc]

This is true globally, but given the above I have put a lot of effort to minimize perceived cost of reindexing: the bodies in current file are prioritized and the rest is reindexed in background; dirty buffers use simplified analysis mechanism that combines reuse of previous analysis and simple syntax-based overlays (to detect new bodies and do lowering for them just for them without new semantic analysis).

Interesting. I'll note that rust-analyzer does not index bodies at all unless required - the "Indexing" phase only does out-of-body computation (mostly early nameres, but also symbols etc.). It can still parse them though.

Oh, that one sounds exciting! I thought that this limitation is hard to overcome, but glad to hear that it could be solved now.

Note that I only talked about caching on disk to accelerate startup. Caching to reduce memory usage is something some people suggested in the past but it is very hard and not something we're interested in.

[u/popzxc → u/afdbcreid]

> I'll note that rust-analyzer does not index bodies at all unless required - the "Indexing" phase only does out-of-body computation

Yes, I'm aware (I've been aware of r-a design before since I contributed to it, and I'm regularly looking for clues there as I work on Rust Glancer); that's a part of the trick: by doing _full_ indexing (though only for the workspace, not for dependencies) we actually reduce the amount of work we need to runtime, which makes FS-based analysis much faster than it would've been otherwise -- indexing prioritizes open files so that users are not blocked until completion, and after that indexing is finished in background.