And I agree that efforts to reduce this are noble and warranted, but I worry about what doesn’t happen because of those optimisations. The rust tooling is just so-so good (and a better argument for the language than memory safety imo), so I support more efforts to be ergonomic over memory optimisation.
Even though rust-analyzer is often the largest memory process on my machine. (and I only have 24GiB of RAM).
They've been working on memory use and it dropped to ~7.5GB for a while but the last couple of releases have been nudging up again - currently 9.4GB without major change in the workspace.
It becomes an obstacle on a 64GB machine given I work with multiple workspaces open e.g. for the crates I am using, example projects, other branches etc. so I have to start/stop it when I just want basic type-info/navigation. Trialling a different editor alongside my current one becomes prohibitive when it's going to want another 10GB for it's own RA instance.
99% of the code isn't changing so disk caching does seem like a no-brainer like back in the 90s with intellisense .ncb files... just without the regular corruptions though!
We're also working to resolve the issues with `rowan` (it's a GSoC project), which should give another major saving.
So I don't deny the idea, just stating that it's probably _significantly_ more complex to implement than it sounds.
It compresses well though on average, if you have something like zram (I think windows/mac do something similar). When you get multiple projects open each with their own rust analyzer though, it starts to bite