about perf issues (and reply to an issue)

[Rudxain]

I've decided to divide this post in multiple parts, as there's a lot to be said. OTOH, I really should stop talking and start studying the code-base to help catch perf problems. I'll later open a Zulip topic (thread?) for communication in my process to understand the codebase.

re: #19402

type inference failures - as you mentioned.

I didn't say that RA is inaccurate. Much the opposite! General-purpose search tools (such as Helix global-search) are less accurate at finding refs. However, if we're talking about reliability in general, there were cases when I had to manually restart RA.

things are getting better as we have been fixing many type errors

I appreciate that! I should've emphasized (more) that I do thank and respect all the work put into this project

Do you have some opinions on what designs of rust-analyzer are problematic and what would be alternatives for them? Rewrite from the ground up with (possibly months of) feature freeze is a big thing, so that would require sufficient discussions, design choices and experiments.

I assume this has been said before: if RA had more "tight coupling" with rustc, both tools could make assumptions about each other that would improve perf. Taking the trait solver as an example, if RA didn't have its own solver, it'd be forced to use rustc's solver, which would be slow the first run, but quick for further runs. So instead of RA generating its own cache (#4712) it could re-use the target/ generated by cargo&rustc.

I understand that rustc's trait solver doesn't always enumerate all symbols associated to a type, but if rustc had a flag like -Ztrait-solver=full then it should generate a cache containing all the symbols found for all types, which RA could exploit to entirely avoid the overhead of trait-solving.

An obvious caveat is that RA would be forced to use a stale cache, which only gets updated when rebuilding (cargo c). But that's fine! (IMO) let the user choose when to rebuild. Many editors rebuild-on-save (and auto-save) by default, so that's a fair trade-off I'd be willing to take.

Alternatively, if RA keeps its own solver (to ensure cache is up-to-date), then there would be a need for a bidirectional synchronization system that could handle concurrent writes to the cache. I believe this one is a terrible idea, both for the complexity, and the locking overhead

project

I want to know which modules are considered "suspicious", that is, which ones are likely candidates for being the culprit behind perf problems.

Since a rewrite seems too radical for now (and I agree), I could help by becoming a "linter human" (not "human linter"), so I'll need some guidance here as I'm very ignorant compared to the maintainers. This information would also serve as guidance for potential contributors!

I've already shallow-cloned the repo, so I can start soon.

campaign?

What if the rust-lang org started some sort of event incentivizing users to find perf problems in RA? Something like hacktoberfest, but not quite. Just a minor suggestion

[ChayimFriedman2]

FWIW, there was actually a "r-a but more integrated with the compiler", which was called RLS, and rust-analyzer was written because it was just too slow.

While it is possible to make a compiler that is both a batch compiler and a language server (Roslyn, the C# compiler, can prove that), it requires an upfront design of the compiler (Roslyn will prove that too - it was a ground-up rewrite of the old C# compiler). rustc is just not designed for that, and designing it for that will most likely involve rewriting it, a very big undertaking that no-one I know of will want to start. And, at the end, we'll likely end up with something like rust-analyzer - probably with fewer bugs than r-a currently have, but by the time this project would have been finished, we could already fix those bugs in r-a.

Using more parts of rustc (aka. the "librarification" effort) is a worthy goal, but there are conflicting priorities here - designing parts of the compiler to be used in rust-analyzer is not a small task (partly due to inherent reasons and partly due to accidental, e.g. r-a wants to compile on stable). T-compiler has rejected some requests for that in the past, and for a good reason.

rust-analyzer does have good foundations. While there are still many improvements that can be made, I don't believe a rewrite will do any better. Instead we should improve the already-sound system we have, and we do! It's just taking time, and we're all volunteers here.

I don't believe there is a single part of r-a that if we can "fix" r-a will suddenly become much faster and less memory hungry. It's cumulative work. And eventually, even a perfect r-a will be too slow/memory hungry for some people. Rust is just expensive to analyze. Even rustc is slow, despite major efforts that have been poured into it.

[davidbarsky]

Since I didn't see this comment be resolved or addressed, it's worth calling out that clangd has a completely different architecture than rust-analyzer. The reason clangd can start immediately on git is that it only analyzes a single compilation unit—on the off chance you don't know what that is, that's roughly a single .c file and all the transitive #includes. However, we can't do that with Rust because Rust doesn't have headers—we often need to analyze the entire project!

If you're curious about some additional background reading on this space, I recommend this post on our blog: https://rust-analyzer.github.io//blog/2020/07/20/three-architectures-for-responsive-ide.html.

This isn't to say that we can't improve rust-analyzer (far from it!), but I think it (I don't speak for the rest of the rust-analyzer team) it'll entail things like:

• Throwing Rayon at our trait solver to reduce autocomplete latency
• Profiling our symbol search extensively.
• Possibly pushing for/implementing WebAssembly procedural macros so that we can run proc macro expansion in parallel during the initial indexing phase.

[Rudxain]

WebAssembly procedural macros

Expanding on that, I assume that means making rustc compile proc-macros in advance (AOT), so that incremental-builds (and RA) can run them optimally, instead of the "traditional approach" of interpreting proc-macros. That'd speedup hot-loops!

And it feels similar to JIT compilation, but more feasible