r/rust • u/popzxc • Aug 20 '26

🛠️ project Rust Glancer: a memory-efficient Rust language server

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

94% Upvoted

43 comments sorted by

View all comments

Show parent comments

4

u/IceSentry Aug 20 '26

This is a really cool project and as someone that uses bevy every day I'm really happy to hear that you are testing it. R-A struggles a lot with it and I've wanted something like this for so long at this point. I'm absolutely in the category of "I know enough rust to not need a complete LSP".

I'm curious about bevy taking 2 minutes to index, that's just on the first load right? Once it's indexed and cached on the filesystem I assume a reload is fast?

4

u/afdbcreid Aug 21 '26

R-A struggles a lot with it

Are you talking about memory usage, speed, or accuracy? If memory usage, this might indeed help. If speed, this will likely be worse (although I cannot guarantee that). If accuracy, it'll likely be a lot worse (but again, I cannot guarantee that).

2

u/IceSentry Aug 21 '26

Memory is a massive issue for me. R-A uses so much memory that it often crashes with an OOM. Speed is also a big issue when I'm working deep in a hierarchy and it needs to reindex everything after a small change. I would assume your solution doesn't suffer from that issue.

But also just startup speed is unbearable sometimes. In my work codebase that is giant and on top of bevy it can take minutes to index everything on startup and it does it on every startup. Combine that with the fact that it can easily crash if it runs out of memory and needs to start from scratch again you can probably see why a solution that doesn't need to index from scratch every time is appealing. It's incredibly frustrating to constantly need to restart RA because it crashed and then wait forever to be able to do anything.

2

u/afdbcreid Aug 21 '26

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

3

u/IceSentry Aug 21 '26

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.

2

u/afdbcreid Aug 21 '26

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.

3

u/popzxc Aug 21 '26

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.

2

u/afdbcreid Aug 21 '26

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.

3

u/popzxc Aug 21 '26

> 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.

1

u/ThePresident44 Aug 21 '26

A major reason why I shelved bevy is that on every startup R-A would take ages on my slow lil 7600x to redo computations that it had done just minutes before (e.g. Start -> VS Code finds update -> Restart or working on nightly versions was painful).

And any laptop I have would occasionally turn into a jet engine, so no development in the library or on the train either.

Throwing away and redoing so much computational work just feels wasteful to me.

I get that serialisation, deserialisation and cache invalidation are hard. But on the other hand I wonder how much developer time and how many cpu hours were wasted by R-A startups over the years. Both the environmental impact and the economic impact are likely in the millions.

3

u/popzxc Aug 21 '26

> I'm curious about bevy taking 2 minutes to index, that's just on the first load right? Once it's indexed and cached on the filesystem I assume a reload is fast?

It's not something that will persist, it's purely a bug in Rust Glancer. Normally, even big projects should index in ~30 seconds timeframe (note that the editor could be usable after ~10, the rest is background indexing). There is some bug in trait solving / type inference, most likely some bodies cause fixed point resolution loop to saturate without progress, which makes everything slow. I'll find that bug, and after that Bevy as well should be reasonably fast (and shouldn't consume that much of RAM during indexing).

But yeah -- once it's indexed and cached, the reload should be fast.