Hey all! First, thanks for the awesome work! :heart:️ I'm working on the winrt crate which is a crate for Windows Runtime bindings (think modern Windows APIs). These APIs are huge and so it's pretty easy for bindings to reach the hundreds of thousands or even millions of lines of code. Needless to say, it's a perf challenge. I'm wondering if it would be helpful to have our crate as a performance measure. You can give it a try with a simple scratch repo we set up: https://github.com/kennykerr/scratch there shouldn't be anything special to run it, just a Windows 10 box.
Could you also create a repo with all the code generated? Might be much easier to poke at if win 10 box is not required :)
Sure. You won't be able to run it, but I guess that's not an issue
Fun fact: IntelliJ Rust had (and I bet still has) special hacks in resolver to handle winapi crate
Interesting note. the generated bindings seems faster than when going through a different create through an
Is there perhaps something when using
include! that might be slowing things down?
Moving stuff around in the file seems to cause it to wonk out though...
I played more with the sample repo I posted above today. Besides a long startup time, the performance is ok. It still takes over a second for some types to resolve. I also am under the impression that performance is different when the code is pre-generated and included explicitly in the project vs when the code is generated in the build script and read by an
include! macro from OUT_DIR. I'm not exactly sure what the next steps should be
Yeah, I think it's quite probable that
include! is a problem here
(or at least one of the problems)
We've fixed an accidently quadratic behavior around
include! a couple of weeks ago but there's still at least one
O(N^2) thing left
Are there tests around this? I need to look into getting rust-analyzer dev set upon my machine
include_accidentally_quadratic test is actually ignored, presumably because it's still pretty slow
I'll see if I can make any dent in that.
@Ryan Levick do you know about
RA_PROFILE env var?
Might be useful to narrow this down. I haven't looked into this myself yet, but the most probable cause is "somethig is quadratic".
Sorry, had to step out. No I didn't know about that (I'm basically completely new to RA dev - only been a user until now). I'll give it a look
https://github.com/rust-analyzer/rust-analyzer/tree/master/docs/dev is worth reading, but
git clone and
cargo test will get you pretty far.
@matklad regarding the performance cc https://github.com/rust-analyzer/rust-analyzer/issues/4692#issuecomment-637076470, it's strange that
codegen-units=1 doesn't increase the dist run time. If so I wonder if it really does give performance increase.
That's compile-time peformance, right? In general, I wouldn't tweak anything here -- at the current level of internal optimization of RA, fine-grained tweaking of compiler optimization flags should be irrelevant -- those should come after the code base itself is optimized.
I wonder if incremental=true negates codegen units?
Incremental=true did this untill 1.44 rust releaae
Setting Codegen-units=1 trades compilation in 1 thread for potentially more optimizations rustc can do.
I also wonder why we have incremental enabled for dist builds...
CARGO_INCREMENTAL: 0 in an
env section at the top of
I mean there is incremental=true release section of cargo toml
Because matklad only runs release builds locally?
Don't we have
[dev] profile for this purpose?
debug=0 is to speed up local debug builds (debug info is huge). incremtal=1 is to speed up local release builds
release.yml doesn't override what is specified in
Or does it?
Ah, yes, the docs say so...
I wonder why I thought it doesn't
codegen-units=1 incremental=false build takes 14 minutes on my laptop
And analysis takes 57.7 vs. 59.8s
I just wiped my target directory because I was running out of disk space. I now have an extra 50GB I didn't have before.