Compile time regression #43141
Comments
Mark-Simulacrum
added
I-compiletime
|
cc @rust-lang/compiler -- Possibly just the standard regression currently caused by MIR borrowck and allocators being introduced, but somewhat seems different. |
Mark-Simulacrum
added
the
T-compiler
|
For WF checking I'd ask @nikomatsakis and @arielb1 specifically. Sounds like a new check was added, or an existing one became much slower. |
|
I just tested on beta ( |
eddyb
added
regression-from-stable-to-beta
|
@Boddlnagg any chance you can run this in some sort of other profiler? I presume it only builds on Windows, right? |
|
@Boddlnagg another awesome thing -- if you are able to do it -- would be bisecting with nightly releases to try and narrow this down a bit more. I don't have easy access to a windows machine, but I'll try to find someone who does also. |
|
Bisection narrowed to 75b0568...14f30da61(commits between nightly-2017-05-16 and nightly-2017-05-21. It seems likely this means #41911 is at fault here, cc @michaelwoerister. No guarantees though. |
|
Ah, #41911 could certainly have done it, though the reason is not yet obvious. |
|
Seems like this won't be fixed for 1.19, but it looks pretty bad. |
alexcrichton
added
regression-from-stable-to-stable
|
@rust-lang/compiler -- this looks like it needs a look from someone to investigate the cause here. |
Mark-Simulacrum
added
the
C-enhancement
|
So after one possibly-unneeded reboot into Windows, it turns out that... drumroll #41911 broke + let relevant: Vec<DefId> = all_trait_impls
+ .non_blanket_impls
+ .iter()
+ .cloned()
+ .filter(|&impl_def_id| {
+ let impl_self_ty = tcx.type_of(impl_def_id);
+ let impl_simple_self_ty = fast_reject::simplify_type(tcx,
+ impl_self_ty,
+ false).unwrap();
+ impl_simple_self_ty == self_ty
+ })
+ .collect(); |
|
@eddyb I thought you were talking about sharing a single |
|
@michaelwoerister Maybe I noticed one problem, but clearly not all of them. |
|
@arielb1 Responding to your ping on IRC, yes, I was able to reproduce via cargo check (just had to pass |
A change in rust-lang#41911 had made `for_all_relevant_impls` do a linear scan over all impls, instead of using an HashMap. Use an HashMap again to avoid quadratic blowup when there is a large number of structs with impls. I think this fixes rust-lang#43141 completely, but I want better measurements in order to be sure. As a perf patch, please don't roll this up.
make `for_all_relevant_impls` O(1) again A change in #41911 had made `for_all_relevant_impls` do a linear scan over all impls, instead of using an HashMap. Use an HashMap again to avoid quadratic blowup when there is a large number of structs with impls. I think this fixes #43141 completely, but I want better measurements in order to be sure. As a perf patch, please don't roll this up. r? @eddyb beta-nominating because regression
A change in rust-lang#41911 had made `for_all_relevant_impls` do a linear scan over all impls, instead of using an HashMap. Use an HashMap again to avoid quadratic blowup when there is a large number of structs with impls. I think this fixes rust-lang#43141 completely, but I want better measurements in order to be sure. As a perf patch, please don't roll this up.
There was a major compile time (and memory consumption) regression when I compare building winrt-rust on Rust 1.18 stable and current 1.20 nightly. (I couldn't test on beta because
error: the optionZis only accepted on the nightly compiler.)rustc 1.18.0 (03fc9d6 2017-06-06): 137.31 secs, 2873 MB peak memory
rustc 1.20.0-nightly (d84693b 2017-07-09): 262.64 secs, 3346 MB peak memory
winrt-rust certainly is a rather exotic crate in that it mainly consists of a > 200k LOC generated file that wraps Windows COM APIs, but something seems to be wrong here, especially in the
wf checkingpass, which went from 8.4 seconds to 96.2 seconds.To reproduce the numbers, you can run
cargo rustc --release --features all -- -Z time-passes(--features allis important, otherwise only part of the crate is being built).The text was updated successfully, but these errors were encountered: