-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Compiler slowdown on lage module in nightly #48153
Comments
Looks like the only PRs in that range are #47571, #47690, #46450, and #47420. None of which seem immediately relevant. I also can't reproduce locally... https://gist.github.com/Mark-Simulacrum/dd7f4c6b0649fabbf598642ddf7c91a2. Are you sure these results are caused by some external process? What platform are you running on? |
I've been able to reliably reproduce this behavior on my desktop. I tried re-running the test on my laptop and saw similar results. Both my laptop and desktop are using NixOS 17.09.2964.3e349a2b98b (Hummingbird) with Mozilla's nixpkgs overlay. The test results with the full invocations are below. The borrow checking stands out though...
vs.
I'm going to go ahead and test this again inside of a fedora container to try to narrow down if this is specific to NixOS.
|
I think I've heard reports elsewhere of similar slowdowns, but I can't seem to find anything right now. I tested on a Ubuntu 17.10 machine, so it's possible nix is somehow at fault here... |
@Mark-Simulacrum Can you try testing with nightly-2018-01-28 (actually |
Yes, I can now reproduce. Based on a quick inspection with gdp, I suspect #47420 is at fault -- I'm seeing CPU time mostly spent in memmove... called from |
After testing in the Fedora container, I'm seeing similar performance so I think it's safe to rule out NixOS's packaging as a factor. Since the time to borrow check seems to be the issue, #47420 is the only change that seems relevant.
|
@Mark-Simulacrum it seems to me like those could be |
Yep, I have a patch locally that seems to solve the problem by removing the allocation. |
…odemap, r=estebank Remove allocation from width of character function. Locally this seems to eliminate the problem or at least resolve most of the issue. Fixes rust-lang#48153. r? @estebank
…odemap, r=estebank Remove allocation from width of character function. Locally this seems to eliminate the problem or at least resolve most of the issue. Fixes rust-lang#48153. r? @estebank
I've noticed that the nightly compilers lately have taken quite a long time to compile efm32gg11b82. The crate is a large amount of code generated by svd2rust. I've narrowed down the difference in build time to a nightly release. The results below are from debug builds, but I've seen similar numbers for release builds.
rustc 1.25.0-nightly (bacb5c5 2018-01-26):
rustc 1.25.0-nightly (7d6e5b9 2018-01-27):
I'm not really sure how to profile this further, so I'll take any suggestion you have.
The text was updated successfully, but these errors were encountered: