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.
In the comparison table, you indicate indexing times. Could you also measure memory usage, since that's the stated goal of the project?
The difference, however, is that with Rust Glancer you don’t need full reindexing often, so it probably compensates for that to a degree.
But importantly it’s not reindexing the entire project, which is the expensive operation. So you have higher peak RAM when opening a brand new project, but much lower RAM usage while working on the project.
And note that on dirty buffers Rust Glancer doesn't do reindexing at all: it reuses the last available analysis, plus it does syntax-based shallow overlay that is sufficient to be useful but doesn't necessarily detect semantic changes. It's a tradeoff, but this tradeoff makes Rust Glancer competitive in terms of latency with rust-analyzer without compromising RAM and while keeping your CPU cool.
> it completely reindexes the single file that’s saved
This is true, though I have to mention that change in the file might invalidate its reverse dependencies, which can make the partial analysis bigger than just one file/crate, but it's still very fast in practice.
This is when you do full reindexing.
> Is that only an incremental indexing with normally low RAM usage?
Yup, on save you only update the crates that were invalidated.
Both the "user configuration" and the library are configuration masquerading as code. One is dynamically evaluated, the other compiled.
I just figure users of Zed know this... so what are we pretending to talk about?
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 :)