Hey! Author here. Happy to answer any questions.
Rust does not have a specification. How do you know your LSP is providing right information?
Rust Glancer: Rust LSP using 100x less RAM
31–40 of 129 posts
Re: Rust Glancer: Rust LSP using 100x less RAM
#32To clarify, author is https://github.com/popzxc , not me! My thoughts are here: https://matklad.github.io/2026/08/21/rust-glancer.html
Thanks for the coverage and kind words!
The title of the post is a bit more ambitious than what I am confident to guarantee, but I'll try my best to live up to it ^_^"
Some comments on the thoughts post
> I think that part can perhaps be made lazy (but not incremental!) with little overhead?
I am still thinking about making stuff lazy, since with non-incremental approach it can introduce more lags than would be perceived comfortable, but what I do right now is that I prioritize open buffers (so the stuff user needs gets processed faster), and everything else is indexed in background. I have some thoughts about lazy approach, but before I'll try them, I want to work on the quality of analysis first.
> Would be interesting to compare memory usage with Rust Rover. Net of the IDE GUI itself, I would expect RR to be more compact.
I've received a few comments about RR already, and, to be honest, I've never tried it (somehow I never got along with JetBrains IDEs) -- but will look into it.
> One potential approach here is to pull the Sorbet trick, where you don’t run meta programming at all, and instead have a plugin interface to “explain” the effects of what that would have done.
Funnily, that's exactly (well, mostly) the idea I have in mind and want to try out. Tentatively planned for Rust Glancer 0.3.0 (0.2.0 will be mostly about more complete indexing/functionality and editors support). In short, I don't want to have random code execution in the LSP itself (even diagnostics are disabled by default), but it's quite possible that we don't need that for proc macros.
> Try changing this option and see if it helps?
I have tried both editor and server watcher options, didn't really feel the difference, but can't say that I performed a high quality investigation. I certainly noticed that vs code is not very good at properly reporting external changes (it misses a lot of them), and the server watcher was tricky to get right (and yeah, it has quite a bit of platform-specific quirks; which is one of the reasons I don't feel comfortable providing a server for Windows yet -- I have no machine to test it).
> This still seems to me to be the lowest-hanging watermelon here — split the world into arcy-pointy incremental tip of the iceberg, and mostly read-only, on disk, compact, dark, moist breeding ground for supply chain attacks.
This would be awesome! And I'd be really happy to see that change making Rust Glancer redundant; while ability to experiment is cool, I think that unified tooling is ultimately better for the language.
Re: Rust Glancer: Rust LSP using 100x less RAM
#33Hey! Author here. Happy to answer any questions.
Rust does not have a specification. How do you know your LSP is providing right information?
Well, most of stuff is not really ambiguous: if you have a struct and found its inherent impl for it, then methods from this impl block are related to this structure. If `a` has type `Foo` and then you have `let b = a;`, then `b` has type `Foo` too.
With things like trait solving I am not reinventing the wheel, and use official tooling (Chalk). Even though now the new solver is recommended, Chalk still does its job and lets me not to worry about potentially the most complex part of the machinery.
In places that seem to be underdocumented, it's always possible to: 1) look into sysroot implementation for clues 2) look into compiler sources 3) hijack stuff from rust-analyzer
I am lucky to not be the first guy who does a Rust LSP, so it's not that fundamental of a research, and much more of just an implementation :)
Re: Rust Glancer: Rust LSP using 100x less RAM
#34Hey! Author here. Happy to answer any questions.
Could you elaborate a bit on why RA's incremental approach takes more memory? Intuitively it feels that it should take less, because you're only processing what you need? Whereas you seem to indicate that you save a full analysis snapshot to disk and load it all up when needed? Shouldn't that consume the max memory for a workspace?
Fantastic project btw, and it couldn't come at a better time. With the way prices are going I really hope people start paying attention to memory again.
Re: Rust Glancer: Rust LSP using 100x less RAM
#35Hey! Author here. Happy to answer any questions.
Could you elaborate a bit on why RA's incremental approach takes more memory? Intuitively it feels that it should take less, because you're only processing what you need? Whereas you seem to indicate that you save a full analysis snapshot to disk and load it all up when needed? Shouldn't that consume the max memory for a workspace? Fantastic project btw, and it couldn't come at a better time. With the way prices are…
It's explained in the blog post, but in short: rust-analyzer stores the data it needs in memory all the time, while Rust Glancer might consume more memory during indexing (because it's not lazy and does more indexing), but after that it only loads _necessary_ information for the duration of the query.
Several things here: 1. We don't need all the information (project can have 1000+ dependencies, while query might only care about the current open file), so the amount of information we load is smaller. 2. Most of the time IDE does not actually do any queries, so if you switch to browser/Slack, you don't pay the tax. 3. Since data is loaded to the disk, after initial indexing restarting no longer consumes that much ram, and you get reindexing for free. 4. Besides offloading, I implement quite a bit of memory optimizations (some of which are covered in docs: https://rust-glancer.github.io/docs/development/MEMORY.html ), so it's a combination of factors.
Re: Rust Glancer: Rust LSP using 100x less RAM
#36RA with disk cache?
In a way. It uses a different architecture, so it's not exactly "RA with something", but the main idea is similar: everything is on the disk, stuff is loaded only when it's needed.
But RA already eats up huge amount if storage when working in a large project, if you're using disk cache, it'll gobble up more, That's the biggest complain I had with RA. Somehow never had this issue with jetbrains rust plugin.
Re: Rust Glancer: Rust LSP using 100x less RAM
#37Re: Rust Glancer: Rust LSP using 100x less RAM
#38wonderful IDEA! Often two much ram cost using nvim with LSP, it may be work!
Forking it!
Re: Rust Glancer: Rust LSP using 100x less RAM
#39Earlier quoted context omitted.
In a way. It uses a different architecture, so it's not exactly "RA with something", but the main idea is similar: everything is on the disk, stuff is loaded only when it's needed.
But RA already eats up huge amount if storage when working in a large project, if you're using disk cache, it'll gobble up more, That's the biggest complain I had with RA. Somehow never had this issue with jetbrains rust plugin.
I’m not sure if RA intentionally uses storage space itself.
It can use storage when running build scripts/expanding proc macros, or when running flycheck diagnostics. In both cases, it’s because it runs cargo and it writes artifacts to the target dir. And if features do not align between “common” cargo commands and configuration rust analyzer has, it can lead to conflicts and even more increased storage size (because you end up having effectively 2 sets of artifacts).
But all of that does not apply to rust glances, since it does not build code for you (even cargo diagnostics are disabled by default).
Rust Glancer analysis artifacts are not that big (it’s basically stuff that would otherwise be loaded to memory), and Rust Glancer cleans garbage so that it does not accumulate over time, so it should be fine.
Re: Rust Glancer: Rust LSP using 100x less RAM
#40Hey! Author here. Happy to answer any questions.
Super nice! Are you planning support for Zed editor?