-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Use hierarchical indexes to speed up module-local completions #14830
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Are you sure they're this slow most of the time and not just right at the beginning? Is your project public? I suspect something else might be going on. |
Yeah, they're always this slow when completing individual functions or trait methods. Namespace completions of module names is fast, but at the leaf level (going from module to type) it is again slow. The project is public, I'm working on the fish-shell rewrite to rust. We have autocxx generate ffi wrappers for (not too much of, to be honest) the C++ codebase as well as the rust code itself. The project isn't massive by any means, but it's decently large - here's what
|
We have some profiling support (https://github.com/rust-lang/rust-analyzer/tree/master/docs/dev#profiling) which may provide more info. |
For this specifically, set |
Thank you both. I was looking through some old issues and was under the impression I'd have to attach a profiler and dig through the dump. |
And please report where you're triggering the completion. Something apparently minor like a proc macro can have a large effect. |
Looking at this though I think I can already guess the problem https://github.com/fish-shell/fish-shell/blob/67d1d80f94107e26585d192d194295180cb9f73b/fish-rust/src/ffi.rs#L20-L136 I imagine this trashes the LRU cache for macro expansions whenever one types causing us to reparse all the macro invocations in there. So this most likely hits #14743 then (which funnily somewhat fits your guess with this being an index problem) or a similar problem where completions reparse macro expansions. Though I'd still like to see the profile to confirm this. |
I can't get Using |
No need to set RA_LOG, just RA_PROFILE should be fine, I think I made a mistake there though, it should be |
I haven't tested that And I think Veykril made a typo there, it's |
I don't know what I'm doing wrong but I can't get it to generate any profiling output. The file is created each time but it remains empty unless I tried Is the |
The log file might not support the profiling stuff, not sure but it looks like it. Can you not access the server logs from neovim? |
I'm trying on a much faster machine now and the completions are snappier but still too long to wait for. I was hoping for native logging functionality because neovim's own log unfortunately escapes the content, giving me this:
If I run it through the shell to try and make it easier on the eyes, I get the following:
This is all from a quick session trying to complete something in a trait impl (without generics) with no proc macros (which I waited for to complete and provide the popup before typing in anything else), so the first is the super slow call as it builds the info for the first time but the subsequent completions are all with a warmed up
|
Sorry for the overly technical and perhaps naive title, but it's the best summary I could think of. On a small project,
rust-analyzer
is blazing fast and all is well. On a large project,rust-analyzer
takes 10+ seconds to generate non-namespace completions.I would expect that if I create a new module in the current crate and have nothing imported,
rust-analyzer
(in that module) would not be too much slower than working on an empty module in a new crate, but this isn't the case.The text was updated successfully, but these errors were encountered: