Change:
pass_name: &str, disambiguator: &dyn Display, source: MirSource<'tcx>, <del> ) -> io::Result<fs::File> { </del> <ins> ) -> io::Result<io::BufWriter<fs::File>> { </ins> let file_path = dump_path(tcx, extension, pass_num, pass_name, disambiguator, source); if let Some(parent) = file_path.parent() { fs::create_dir_all(parent)?; } <del> fs::File::create(&file_path) </del> <ins> Ok(io::BufWriter::new(fs::File::create(&file_path)?)) </ins> } /// Write out a human-readable textual representation for the given MIR.

Discussion:
is it possible this is all time spent in processing the output? cc
I can't reproduce anymore, but I've seen this before (usually just one message).
Maybe made emitting all this MIR really slow?
I think these have been slow for quite a while though.
is now my main bottleneck in running the tests (if not for , it would be the only bottleneck in the entire build+test process), these are the numbers: Bonus: I get these messages (which hint to the slowest of all tests, although perhaps I would want the message to be configurable, I consider tests that take over 10 seconds "effectively broken"): test [mir-opt] mir- has been running for over 60 seconds test [mir-opt] mir- has been running for over 60 seconds
Nominating for discussion (specifically, investigating this) at the next team meeting.
I wanted to try get warnings for 10s instead of 60s, but sadly, it's hardcoded into : And because we build against downloaded , I had to add (to 's ) , and comment out . <hr/<details<summaryHere are the warnings for <codemir-opt</code(click to open)</summary</detailsThis is terrible: 33 out of 42 tests take longer than 10 seconds. And we haven't really noticed because of our (huge) minute-long warning delay. <details<summaryThe only other test suite that gets any warnings is <coderun-pass</code(click to open)</summary</detailsThat's only 7 out of 2957, and some (all?) of those are intentional stress tests.
Wow, how do you get such times? takes many minutes for me, that's like 3k tests or so?
As I mentioned in , this is a machine.
One solution and I are considering is adding an analogue of LLVM's , but for MIR, and as an alternative to (which creates a directory with many files). Then, we can mostly use UI tests instead of .
triage: It would be great to resolve this. It would also be great if all of our rustc developers had a machine so that we would all share the same problem here. however, I think given the reality of our common-case hardware, I do not think this falls into the P-high prioritization bucket. (Again, I do want to resolve it.

but I don't want to revisit it's status every week.) So I'm going to assign this P-medium priority for now. (And leave it nominated for discussion at the meeting.)
Removing nomination since it's not clear what's left to discuss at the meeting.
Not sure whether it's a change in the build server I'm using, or Rust itself, but while the other passes take more or less the same time, I've recently observed an increase in times from to (and most, if not all of them, now warn about taking more than 60 seconds).
Huh, I wanted to do some other testing and found these results for : That is, the more threads (forced with ), the longer the total time it is, and the more "running over 60 seconds" messages are printed. Keep in mind there's only tests to begin with. and seem to sometimes be lower than but are less reproducible (presumably because of which tests happen to overlap with which others?), so I didn't include them. I wonder if it's caused a lot of contention, maybe IO (since writes a lot of files)? The testsuite (including ) still manages to run tests in , so even if this machine has gotten a bit slower, is disproportionately affected.
Okay all that analysis was pointless except it led me to realize all of those processes are producing likely millions of syscalls. takes only a couple seconds once it's buffered (PR up at ).