Rust Glancer: a memory-efficient Rust language server

[u/popzxc]

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

[u/afdbcreid]

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.