Disable indexing every crate in workspace while only one crate is opened.

[jkelleyrtp]

I'm not sure if there's a setting anywhere, but every time I open an individual crate in a workspace, Rust-analyzer indexes every single dependency that every crate has (1200+ crates just for a tiny crate in the workspace). Save/Reloading takes forever.

Is there a way to disable this?

[lnicola]

I'm not sure if there's a setting anywhere, but every time I open an individual crate in a workspace

The indexing step should only happen once per start-up. Is that a Code workspace with Rust and maybe other languages?

Save/Reloading takes forever.

That's probably running cargo check. You can disable that, but you'll lose the rustc diagnostics.

[oeed]

You could take a look at #8362, I encountered similar issues - although not that many crates.

[jkelleyrtp]

Closed by #10743

[jkelleyrtp]

Actually - not quite closed. Fewer crates are being indexed in workspaces, but RA still indexes transitive dependencies of other crates in the workspace even if only one smaller crate is open.

[lnicola]

Fewer crates are being indexed in workspaces, but RA still indexes transitive dependencies of other crates in the workspace even if only one smaller crate is open.

I think we do that to.. have finer progress reporting doing the cache priming? CC @jonas-schievink

[jonas-schievink]

We do that so that when you open another workspace file, its dependencies are already processed and you get IDE features quickly. We could make indexing aware of the set of opened files, but I'm not sure if that is a good idea.

Note that indexing won't impede IDE usage in files that already have all necessary data available, and it should also never prevent you from saving or closing files, or from switching to another workspace. If it does that, that's a separate bug.

[lnicola]

But what if we ran it only for the crates in the workspace, without their dependencies? In an eyeball test, it seems to finish in about 7 s instead of 8.

Do we want to run the priming on e.g. instant just because there's a base_db -> salsa -> parking_lot -> parking_lot_core -> instant dependency chain?

---

Looking at the CPU time with no open files, there doesn't seem to be a large difference, but the memory usage is slightly lower (541 MB vs. 558 MB).

[jkelleyrtp]

I opened this particular issue because every time I open a tiny crate in my workspace (>30 total deps), RA starts to index a bunch of crates (1200 before, 300 now) and my battery life drains / laptop gets real toasty. It would be convenient to have a way to disable indexing of other workspace crates that aren't dependencies of the opened crate to save battery life.

[lnicola]

Yeah, ideally the priming would be configurable. Without it, the first requests will be visibly slower, but less likely to spin up your fans. In Code you'll get a limited version of the priming anyway because the semantic highlighting and inlay hints end up doing the same thing.

[jonas-schievink]

Do we want to run the priming on e.g. instant just because there's a base_db -> salsa -> parking_lot -> parking_lot_core -> instant dependency chain?

Ah, yeah, we do use transitive dependencies here to provide better progress. We can definitely play around with just not doing that, if it helps.

[lnicola]

#10978 should have helped here, but #10810 added a preference to disable cache priming. I think this can be closed now.

[jkelleyrtp]

Not sure if this has been fixed since 2021 or if it recently became an issue, but the issue has returned (or never went away?) and editing in vscode with large workspaces is frustratingly slow. I use very few extensions (RA + Github Copilot + GitLens + ErrorLens).

Any time I save, VSCode freezes and stutters while RA is printing out dozens of crates in the workspace that I'm not actively editing.

I have an M1 so I'm certain my machine is not too slow.

Screen.Recording.2022-10-02.at.3.27.30.PM.mov