Rust Analyzer formatting/checking is slow, blocks file saving and only rechecks file on save.

[Nufflee]

Rust Analyzer formatting/checking takes >600 ms when saving a file and it blocks the file from actually saving when I press CTRL+S. This is really annoying because I want to cargo run immediately after saving and I often run the old version of the code and wonder why something is broken.
It would be great if this actually didn't block saving and would let the file to be written to the disk before checking & formatting has finished, and it can be saved again when all of that is done. Especially because formatting won't impact the running of my program and cargo run will do all of the checking before compilation anyways.

I'm not exactly sure why this whole process is so slow (even on small files, this one in particular is <200 LOC) but making it faster would certainly greatly improve user experience.

It would also be great if the checking of the file (for compilation errors) would happen periodically, and not only when I save the file.

Relevant log:

...

[ERROR rust_analyzer::main_loop] overly long loop turn: 621.9104ms

...

[ERROR rust_analyzer::main_loop] overly long loop turn: 639.4545ms

...

[ERROR rust_analyzer::main_loop] overly long loop turn: 642.6391ms

[bjorn3]

Rust Analyzer formatting/checking takes >600 ms when saving a file and it blocks the file from actually saving when I press CTRL+S.

I don't know how auto formatting works, but when auto formatting is disabled, files should immediately be saved to the disk. If you then run cargo run, it will simply wait for the cargo check invoked by rust-analyzer to complete.

It would also be great if the checking of the file (for compilation errors) would happen periodically, and not only when I save the file.

You can enable autosave. It is not possible to check for most compilation errors without saving. Rustc only supports reading files from the disk. There is no way to tell rustc to read files from the memory of rust-analyzer.

[matklad]

Hm, 600 ms for a loop turn is definitely a bug, but this seems hard to debug -- we definitely don't see this usually, so it must be some environment peculiarity.

So, this needs a minimal reproducible example and abundant info about environmnt (OS, versions of things, etc).