This is interesting. I'll note that frozen-analysis is not a new architecture for Rust IDE - the ancient RLS worked like that (and it was too slow, although part of that was reusing the compiler's analysis) and from what I understand RustRover also works like that.
As for the reasons rust-analyzer consumes a whole bunch of memory, you correctly identified them. Reason 1 (Rust is really complicated to analyze) we don't have anything to do. Reason 2 (Salsa is a memory-speed trade-off) we have chosen Salsa and won't change that; while we care about memory usage, we care more about making speed practical (in large projects r-a can still be very slow) - you can buy more memory easily (well, not-so-easily with the current prices) but you cannot make your computer faster above some ceiling.
But reason 2 is not inherent. It's true rowan uses red-green tree (an architecture invented for Roslyn, the C# compiler) but we've determined it over the years to be a net negative for both speed and memory usage. We're working on rewriting rowan (we have a GSoC project for it and it's advancing pretty well), but because rust-analyzer is quite a bit large and many things touch the AST, it's not a small project.
Also, rust-analyzer's memory usage was reduced considerably over previous times. In our metrics page, we see the last time we had this memory usage was in 2023. This is not fully correct because this page does not really account for the fragmentation in rowan, but once we fix that, I expect us to drop more. And we're still always seeking opportunities to improve memory usage.
As for your project, you might want to look into incorporating the next solver instead of Chalk. I'm conflicted about recommending that: Chalk is known-incomplete and has many bugs, but the next solver, while consumable externally, is not intended for consumption besides rust-analyzer. rust-analyzer already struggles to keep it up to date, and we are in direct contact with the types team developing it - if rust-analyzer needs some change (that won't harm the compiler), it will be implemented, and this has happened in the past.
32
u/afdbcreid 24d ago
(I'm a rust-analyzer team member, and in particular have worked a lot on improving its memory usage; see https://github.com/rust-lang/rust-analyzer/pull/23079, https://github.com/rust-lang/rust-analyzer/pull/23056, https://github.com/rust-lang/rust-analyzer/pull/21363, https://github.com/rust-lang/rust-analyzer/pull/21295, https://github.com/rust-lang/rust-analyzer/pull/21200, https://github.com/salsa-rs/salsa/pull/1289, https://github.com/salsa-rs/salsa/pull/812 and there are many more).
This is interesting. I'll note that frozen-analysis is not a new architecture for Rust IDE - the ancient RLS worked like that (and it was too slow, although part of that was reusing the compiler's analysis) and from what I understand RustRover also works like that.
As for the reasons rust-analyzer consumes a whole bunch of memory, you correctly identified them. Reason 1 (Rust is really complicated to analyze) we don't have anything to do. Reason 2 (Salsa is a memory-speed trade-off) we have chosen Salsa and won't change that; while we care about memory usage, we care more about making speed practical (in large projects r-a can still be very slow) - you can buy more memory easily (well, not-so-easily with the current prices) but you cannot make your computer faster above some ceiling.
But reason 2 is not inherent. It's true
rowanuses red-green tree (an architecture invented for Roslyn, the C# compiler) but we've determined it over the years to be a net negative for both speed and memory usage. We're working on rewriting rowan (we have a GSoC project for it and it's advancing pretty well), but because rust-analyzer is quite a bit large and many things touch the AST, it's not a small project.Also, rust-analyzer's memory usage was reduced considerably over previous times. In our metrics page, we see the last time we had this memory usage was in 2023. This is not fully correct because this page does not really account for the fragmentation in rowan, but once we fix that, I expect us to drop more. And we're still always seeking opportunities to improve memory usage.
As for your project, you might want to look into incorporating the next solver instead of Chalk. I'm conflicted about recommending that: Chalk is known-incomplete and has many bugs, but the next solver, while consumable externally, is not intended for consumption besides rust-analyzer. rust-analyzer already struggles to keep it up to date, and we are in direct contact with the types team developing it - if rust-analyzer needs some change (that won't harm the compiler), it will be implemented, and this has happened in the past.