upvote
I wish it only took 2gb on my project. It regularly goes over 8gb, I started running it in a cgroup limited to 8gb so it gets killed when it goes over instead of causing problems for the rest of my system. Hits it all the time. I have 64 GB of ram, but my project uses docker to monitor games servers which are also ram hungry so it's still a huge problem when testing. RA acts like they expect to be the only thing running on your pc.
reply
It wasn't long ago RA was consuming over 24GB for my main workspace.

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!

reply
> rust-analyzer taking 2GiB of RAM per instance definitely hurts.

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

reply
I would think there has to be some decent middle ground like storing some structures on disk mmap'd and letting the kernel handle back pressure and caching
reply
Storing structures mmapp'd is actually very tricky. I have experimented with rkyv initially having this idea in mind, but gave up because the machinery just to power the archive types was causing complexity to explode. The thing with zero-deserialization frameworks is that they are very limited in what they can abstract away, and it gets ugly pretty quickly.

So I don't deny the idea, just stating that it's probably _significantly_ more complex to implement than it sounds.

reply