Repository navigation
Compiler slowdown on lage module in nightly #48153
Description
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):
$ CARGO_INCREMENTAL=0 cargo build
Compiling aligned v0.1.1
Compiling bare-metal v0.1.1
Compiling cortex-m v0.4.3
Compiling vcell v0.1.0
Compiling untagged-option v0.1.1
Compiling volatile-register v0.2.0
Compiling efm32gg11b820 v0.2.0 (file:///home/alex/efm32gg11b820)
Finished dev [unoptimized + debuginfo] target(s) in 233.85 secs
rustc 1.25.0-nightly (7d6e5b9 2018-01-27):
$ CARGO_INCREMENTAL=0 cargo build
Compiling cortex-m v0.4.3
Compiling aligned v0.1.1
Compiling bare-metal v0.1.1
Compiling vcell v0.1.0
Compiling untagged-option v0.1.1
Compiling volatile-register v0.2.0
Compiling efm32gg11b820 v0.2.0 (file:///home/alex/efm32gg11b820)
Finished dev [unoptimized + debuginfo] target(s) in 2358.13 secs
I'm not really sure how to profile this further, so I'll take any suggestion you have.
Activity
Mark-Simulacrum commentedon Feb 12, 2018
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?
crawford commentedon Feb 12, 2018
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.
Details
Mark-Simulacrum commentedon Feb 12, 2018
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...
crawford commentedon Feb 12, 2018
@Mark-Simulacrum Can you try testing with nightly-2018-01-28 (actually
rustc 1.25.0-nightly (7d6e5b9da 2018-01-27))? That's the version where I start to see the failure.Mark-Simulacrum commentedon Feb 12, 2018
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
syntax::codemap::CodeMap::find_width_of_character_at_span. I suspect the problem is the String allocations here: https://github.com/rust-lang/rust/pull/47420/files#diff-c5bde8c46eebaa8f5890c6f3700793b3R675.Mark-Simulacrum commentedon Feb 12, 2018
cc @estebank @davidtwco
crawford commentedon Feb 12, 2018
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.
Details
estebank commentedon Feb 12, 2018
@Mark-Simulacrum it seems to me like those could be
&strinstead...Mark-Simulacrum commentedon Feb 12, 2018
Yep, I have a patch locally that seems to solve the problem by removing the allocation.
Rollup merge of rust-lang#48167 - Mark-Simulacrum:remove-allocation-c…