There's some performance regression between nightly-2023-06-28 and nightly-2023-07-01.

Compilation times for my company's firmware project went from 13s on nightly-2023-06-28 to 1m 43s on nightly-2023-07-01. This is for "change a single line, then build", not for a cold build.

The project is a single rather big crate making extensive use of async and AFIT, and TAIT through the #[embassy_executor::task] macro to place futures in statics. Unfortunately it's not open source. I also haven't been able to isolate the regression to a single bad pattern of code causing it. It seems all async code contributes to the slowness: as I remove code compilation gets faster, and it seems linearly proportional.

I've taken flamegraphs with -Zself-profile. The extra time is spent in codegen_module -> fn_abi_of_instance -> deduced_param_attrs -> is_freeze_raw -> evaluate_obligation

nightly-2023-06-28, 13s: flamegraph
nightly-2023-07-01, 1m 43s: flamegraph

I do have one open-source project which also seems affected by the regression, but not as egregiously. To reproduce, cd examples/nrf; cargo build --release.

3 attempts of "change 1 line then build":
nightly-2023-06-28: 2.51s 2.85s 3.51s. flamegraph
nightly-2023-07-01: 4.22s 4.10s 4.09s. flamegraph

fn_abi_of_instance takes 14% of the time in the new nightly, but barely none in the old one. So it seems it's the same issue.

Also unfortunately nightly-2023-06-29 and nightly-2023-06-30 have an unrelated (?) bug which makes compilation fail with bogus "impl ?Sized is not a Future" errors, which is #113155 (introduced in #98867, fixed in #113165). I don't think that's the cause of the perf regression, but it prevents bisecting it (it just points me to #98867. Scripting the bisect to fail only on timeout would probably point to #113165, though I haven't tried)