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.
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.
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 :)
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.
Your thoughts are quite cool! but I thought featuring the project itself would make more sense for a frontpage thread, so I'm going to merge the comments (such as they are) from https://news.ycombinator.com/item?id=49392654 and add your link to the toptext above. Thanks for drawing attention to this topic!
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.
Waiting for RA to build up the full in memory data structure for a large workspace is so painful. Honestly, I'd just assumed that was the only way and didn't realize Rust Rover was different.
Does anyone have experience using that? Any tradeoffs?
It does up until a point. Would you say the same about "AI"? What about "LLM"?
On HN (Hacker News), I expect that most would find a definition for AI or LLM to be redundant today. LSP is borderline in my opinion, especially when the context of Rust is already given.
You made yourself an expert in Rust and have never heard of an LSP?
This seems surprising to me given that Rust was one of the first languages to broadly advertise a toolchain and editor integrations which rely on the technology.
I just put VScode in vim mode and rely on its basic symbol completion. My goal has always been to write as little as possible by thinking out the minimum solution. The simpler the code, the easier it is to reason about and to maintain.
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.
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.
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 :)
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.
Does anyone have experience using that? Any tradeoffs?
This is why Rust (it’s a systems programming language) and LSP (the language server protocol invented by VS Code) are not explained in the article.
I am hoping I don’t have to define the words I used, but if in doubt, Google or ChatGPT are your friends.
It does up until a point. Would you say the same about "AI"? What about "LLM"?
On HN (Hacker News), I expect that most would find a definition for AI or LLM to be redundant today. LSP is borderline in my opinion, especially when the context of Rust is already given.
LSPs are orthogonal to both LLMs and VSCode. For example, see Metals[0].
0 - https://metals-lsp.org/
This seems surprising to me given that Rust was one of the first languages to broadly advertise a toolchain and editor integrations which rely on the technology.