Slow startups - Opening Vscode blocks the target directory and cargo commands

[aminya]

I am unsure if I have to configure the rust analyzer in a certain way. Still, after opening a big Rust project, the rust-analyzer blocks the target directory and disallows running any Cargo command.

In the status bar, it stucks on fetching metadata or cargo check for a long time. This happens while the project has been already built, and if I run cargo check from outside the VSCode, it will run in seconds.

I sometimes just kill VSCode to be able to run a simple cargo run command for an already built binary.

I am on Windows 11.

[Logarithmus]

Do you override CARGO_TARGET_DIR?

[aminya]

Do you override CARGO_TARGET_DIR?

No, I don't.

[Logarithmus]

@aminya try doing this:

1. Close VSCode. Make sure rust-analyzer doesn't running via Task manager.
2. Delete target directory
3. Open VSCode, but don't run cargo check manually
4. Wait till rust-analyzer finish initial analysis & running cargo metadata & cargo check
5. Copy the whole target directory to e. g. target2, so you have both target & target2
6. Repeat step 1
7. Now run cargo check manually from the terminal (or whatever it's called on windows)
8. After cargo check is finished, compare the size of target & target2. After that look inside & compare the files inside both directories. If target contains the files which are not present in target2, it means rust-analyzer probably passes some weird arguments to cargo check so cargo check can't reuse the build artifacts.

[aminya]

I tried these on the rust-analyzer project itself, and the folders were equal to each other. So I guess the problem isn't that. However, it took a long time for the Rust analyzer to finish this, which is understandable due to its complexity.

[aminya]

I realized that I had "Cache Priming" enabled. The description of the setting didn't explain enough that this is a bad setting and that enabling it can slow down the whole editor startup. By disabling it, the rust-analyzer becomes ready much faster.

I think the description of this setting needs to include a warning about the performance regressions.

[Veykril]

This is an inherent issue with how cargo works. You can work around this by setting r-a's target dir to a different one at the expense of duplicating artifacts.