-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Significantly slower --emit=metadata #47267
Comments
IIRC, metadata generation is the first point where we compute the MIR of most functions, so the slowdown does not have to be specific to metadata encoding. |
According to the list of changes the candidates probably are:
@leonardo-m would you be able to share detailed instructions of how to reproduce? Testing the two nightlies in question on rust-ndarray/ndarray@bda4c0d doesn't show much differnce to me for |
So far I haven't found a better way to reproduce the problem, my code is not public. But if no one else is having this problem, then it's just a problem of my code, and I'll close down this issue. A simple thing that I didn't think about using is "-Ztime-passes --emit=metadata":
The only significant difference I am seeing in those two listings is for the borrow checking: A: time: 1.079; rss: 186MB borrow checking B: time: 1.955; rss: 188MB borrow checking So the cause could be the NLL changes. I have an open issue about NLL ( #47022 ), so I can't compile my code with |
Huh, that's interesting. I don't have much of an idea why that would be. It'd be really nice if we could try to reproduce this with some standalone file. |
I'm tagging it as WG-compiler-nll for now. |
This is a problem related but different from the main one discussed above. The last Nigtly (1.25.0 3f92e8d 2018-01-14) is finally able to compile my code if I add the nll feature. But compiling it with "--emit=metadata" goes from 5.30 seconds to 31.84 seconds (about 6X slower). If I also use "-Ztime-passes" I see the differences:
|
Ouch |
@leonardo-m perhaps you can run with (How private is the code? If you are willing to send via e-mail, I'd of course promise not to redistribute.) |
Yes, I could send you all the code. But first let's try with an example I've found. This small program shows some timings difference compiling with "--emit=metadata" (0.47 seconds with nll, and 0.27 seconds without):
|
@leonardo-m thanks =) |
Some notes on the runtime of this test that I've extracted from profiling:
|
Browsing the MIR for the main function is interesting (here is a gist), you can definitely see some of the density/sparsity of the region values. |
Some numbers of @leonardo-m example, with and without this PR #47766 Without PR
With PR
With PR, NLL turned off
So, there's still a lot to improve but getting closer 😄 |
The compile time with --emit=metadata and nll feature has improved a bit, but it's still about 5X slower. The compile time without the nll has improved in the last two nightlies and it's now almost OK. |
Since the last Nightly the compiler improvements have essentially put the compiler back to the original performance discussed here. The performance of the NLL feature is discussed elsewhere, so I close down this issue. |
I have found a significant time increase when I use "rustc --emit=metadata". I have located the source of such difference between two Nightlies, that I've named A and B, the time is for my code:
If you perform a complete compilation instead of just --emit=metadata the timing difference between the A and B compiler is of course much smaller. But --emit=metadata time is important to verify the code.
To show an example I've done:
cargo check --all
On rust-ndarray version 0.11.0, with both A and B. Then I've cleaned the directory:
rust-ndarray-master\target\debug\deps
And I've done "cargo check --all" again for both both A and B. This is not the best test for this problem, but it shows a difference (25.76 seconds for A, and 26.75 seconds for B), the difference percentage is small because it's not equivalent to just a "--emit=metadata".
The text was updated successfully, but these errors were encountered: