Description
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 static
s. 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)