I'm currently noticing a problem where rust-analyzer stops responding to any queries and pegs a CPU core seemingly forever. This happens regularly when working on a new file I created in the rust compiler under
src/librustc_mir/transform/dag_nrvo.rs. I've posted the contents here but I'm not sure that's enough to reproduce the issue.
Has anybody seen a hang like this before?
Hmm, I wrote some more code and now the issue seems to be gone
Still seems to be an issue, unfortunately (as of commit 176f7f6)
Not entirely sure how to reproduce the issue, or how to profile r-a, but running
analysis-stats panics with this error:
thread 'main' panicked at 'no value set for FileTextQuery(FileId(9280))'
It also outputs a bunch of cyclic dependency errors (that don't seem to cause any issues so far)
2958 textDocument/codeAction 132438ms
That analysis-stats panic might be https://github.com/rust-analyzer/rust-analyzer/issues/3888
Submitted https://github.com/rust-analyzer/rust-analyzer/pull/3939 to fix that panic.
However, there is another panic related to Chalk ..
I've narrowed this down to the "bad offset" crash that was reported a while ago. I've added a backtrace here: https://github.com/rust-analyzer/rust-analyzer/issues/4058#issuecomment-625500413
It looks like r-a is still pegging 6 cores after the crash though, which makes it seem like there's more to this
Now it froze the Electron renderer process. This code is just cursed.
The plot thickens...
341143ms - add_missing_impl_members_inner 0ms - Semantics::analyze2 (3 calls) 10164ms - crate_def_map:wait (82825723 calls) 10ms - enum_data_query (10 calls) 0ms - parse_query (1 calls) 330968ms - ???
5+ minutes for this... is not normal, right?
Oh, I was editing in a
MutVisitor when this happened, that trait has quite a few items (but way fewer than eg.
Opened https://github.com/rust-analyzer/rust-analyzer/issues/4498 for further investigation
Any idea why
crate_def_map:wait takes over 100ms per invocation? Seems like it really shouldn't, once the def map is computed once.
I think it means either of the two:
You mean verification as in checking that the input didn't change?
It looks like
find_path is what takes most of the time here
importable_locations_in_crate brought the entire ordeal down to 20 seconds
Not sure if that's a good approach though
Hmm, I feel like
ra_prof sometimes wrongly attributes time spent somewhere. And here the indentation here looks weird (but the times kinda make sense?):
20399ms - add_missing_impl_members_inner 0ms - Semantics::analyze2 (3 calls) 0ms - crate_def_map:wait (2038 calls) 9ms - enum_data_query (10 calls) 20366ms - find_path (347 calls) 0ms - Semantics::analyze2 (4 calls) 6ms - add_missing_impl_members_inner (1 calls)
sometimes wrongly attributes time spent somewhere.
I had this feeling as well, though I haven't dug into it
The indentation in the example seems ok?
3 outer functions are on the same level
nested funcitons are nested
-) is the level of indent, not the number
find_path is also used by the auto-import machinery, right? I think I've seen it working surprisingly long, so I bet there's some stupid tihng hidden there
-) is the level of indent, not the number
Oh, okay. I thought the whitespace in the front was.
Yeah it is
< aligned timings look weird. It looks much better if you don't have 20 seconds outliers
Wait, are you runing ra_profile with big cutoff?
Ah, that explains why we collapse 347 calls
I don't understand why 0ms calls are still showing up with that
we show one-level of 0ms calls, to make sure that everything is printed
Like, we skip the children, but we show first-level, to make it clear that the profiling acutlaly works
Ah, okay. So probably I'm just misinterpreting the output and it's measuring correctly.
find_path call still takes around 100ms, and there's a huge number of paths in the default impls, so that explains why it's still slow
I think many of those are for the same item, maybe some more aggressive caching would help
173ms - QualifyPaths::get_substitution_inner 173ms - find_path 10ms - crate_def_map:wait (32769 calls) 122ms - find_importable_locations (16384 calls)
I think there are at least three wrong things here:
One thing that the
find_path code does is looking up a name in every module of every dependency, and in the current crate as well. That might explain the high query counts.
Yeah, that probably is bad
I originally had a query for this in the
find_path PR, we removed it because it wasn't clear it was really necessary :grimacing: