rust-analyzer is slow to compile #1987
Comments
|
Codegen seems to be taking an awful lot of time... With
But overall that's just a tiny improvement. |
|
At the moment we carry around 2 versions of winapi which adds over 30 seconds to my build. I can get it down to (I think) one version of 0.2.8 being held back by mio. |
|
@inicola is that cargo timings with |
|
Yeah, and 102s by default. Maybe there's a lot of generic code? |
|
Hm, that reminds me that we should set debug = 1 for the dev profile, to save some disk space... |
|
Another interesting thing is that I tried to use |
|
Some random
|
matklad
changed the title
|
Will further modularization help? |
|
Might be relevant for |
|
On thing that helps a bit is using lld: |
|
That's strange, I tried it a couple of times, and it made zero difference for RA. It does help a lot on other projects. |
|
Since I now got a fancy desktop PC which is not generally slow here is another observation: The compile cycle does barely use any parallelism. The following is the CPU utilization for a small edit and recompile inside a file in The whole |
|
I think small, incremental edits parallelize inherently worse, because there's less to compile. Still, it's not so bad:
But it's surprising how much debug info slows things down. Same scenario,
|
|
How could one disable |
|
That's how, but you might not need to stash that often. I generally use pull --rebase with autostash, so it doesn't come up most of the time. |
|
Hm, should we put debug=0 into Cargo.toml? I think I personally can live with that, especially if it makes printf debugging faster :-) We loose line numbers in backtraces, but I think I rarely look at backtraces (but we should retain debug=1 for releases, so that folks can get a useful backtraces from the debugger). On the side note, one of the things I miss most from IntelliJ is the ability to colorize and linkify backtraces. If we could link rust::paths from backtraces to functions, that would be sooo helpful. |
That depends on whether you're testing on debug or release builds. Re backtraces, unfortunately |
|
Well, I use rust-analyzer always with |
|
It feels like it became significantly works for |
|
Some measurements from today and a time before
:( :( :( |
|
I haven't looked over the code (not sure what the polymorphic code is), but is there a way to avoid that, maybe by introducing monomorphic wrappers? |
|
So "introducing monomorphic wrappers" is exactly what Ie, making DB non-generic does not work (or, rather, makes things worse), because all functions are still generic, but are now monomorphised in each crate that uses a non-generic database. |
Do you mean things like |
|
That as well, but mostly all query definitions, like |
|
(though, I still haven't really debugged this properly, my understanding of how monomorphisation happens might be wrong) |
|
I can't try right now, but I'm curious what happens on a non-LTO build. It seemed to me that half of the build time was spent during linking. |
|
Maybe cargo-llvm-lines could help us identify some hot spots. |
|
Some results on the |
|
And I'm not sure how actionable these are. |
|
Yeah... I was hoping it would show us if there were a lot of monomorphized things we could reduce. |
|
@lnicola @kjeremy Note that Both PRs reduced the number of llvm-ir lines generated and improved compile time. They will land on stable in next Rust release in July, so until that, you might want to measure with |
|
@panstromek thanks for the heads-up. I ran it again on ra_ide_db LLVM lines |
|
It feels like we're getting slower and slower:
|
|
To things jump at me as odd:
* it feels like ssr should not be that heavy
* chalk is too light
…On Wednesday, 1 July 2020, Laurențiu Nicola ***@***.***> wrote:
It feels like we're getting slower and slower:
[image: image]
<https://user-images.githubusercontent.com/308347/86206821-f093b080-bb75-11ea-815d-9973bee870cb.png>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1987 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANB3M7FRVZECURZQ77T3GTRZLDOTANCNFSM4I7OUNRA>
.
|
|
5153: Make SemanticsScope non-generic r=matklad a=lnicola This slightly reduces the build times:  (compare to #1987 (comment)) Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
|
After #5242:
|
|
One of my tests is to compile a new crate containing only this code: use hir::Semantics;
use ra_syntax::{ast, AstNode, SyntaxNode};
pub struct MatchFinder<'db> {
sema: Semantics<'db, ra_ide_db::RootDatabase>,
}
impl<'db> MatchFinder<'db> {
pub fn new(db: &'db ra_ide_db::RootDatabase) -> MatchFinder<'db> {
MatchFinder { sema: Semantics::new(db) }
}
pub fn find_matches(&self, code: &SyntaxNode) {
if let Some(macro_call) = ast::MacroCall::cast(code.clone()) {
self.sema.expand(¯o_call);
}
}
}It takes 11.5 seconds (vs. ~35 last week). |
|
Much more reasonable! |
|
Substantial amount of the rest seems to be serde-generated code. Not sure how to combat that.... |
|
@lnicola do you have up-to-date CPU usage metrics over time? |
|
We're pretty good on that front: |
|
Yeah, overall CPU usage looks very reasonable with exception of small 5 seconds window where only 3 threads are properly utilized. 16 thread CPU reveals some bottlenecks though: |
|
I wonder how much do we pay for may AST methods being trait methods. It might make sense to experiment with generating all methods as inherent methods, and then implementing traits via delegation to inherent methods. This will also reduce the amount of imports we od. |
|
We should also try the self-profiling feature. Last time I wasn't really able to understand the profile output -- it seemed to me that ThinLTO took up to 80 seconds for some CGUs, but I didn't have a baseline to compare it with. |
5300: Update deps r=matklad a=kjeremy Bumps tracing to 0.1.16 which reduces monomorphization: #1987 (comment) Co-authored-by: kjeremy <kjeremy@gmail.com>
|
Let's close this: we implemented a couple of optimization in this space recently, and I feel that the compile times are reasonable . One of the optimizations was to fix thermal throttling bug in my laptop: #5903 (comment) =/ |
Wrong link? |
|
Here's a fresh
|
Both
ra_hirandra_ide_apiare really slow to compiler, which makesfix & testloop rather frustrating. Note that tests are extremely fast themselves, it's compile time that hurts us badly.We need to do something with it...
The text was updated successfully, but these errors were encountered: