MIR_borrow_checking and MIR_effect_checking are very slow

[programmerjake]

I tried this code:

https://git.libre-chip.org/libre-chip/fayalite/src/commit/25aa90ec603acdc49a984588e75ba62d7f16b5c4

I expected to see this happen: compile in a reasonably short time

Instead, this happened:
running cargo +nightly rustc -p fayalite -- -Z time-passes gives small times for everything except:

time:  25.136; rss:  396MB ->  782MB ( +386MB)  MIR_borrow_checking
time:  22.335; rss:  782MB ->  973MB ( +191MB)  MIR_effect_checking

I'm running on a Ryzen 9 7950X so this isn't just a slow cpu.

Meta

rustc --version --verbose:

rustc 1.81.0-nightly (8337ba918 2024-06-12)
binary: rustc
commit-hash: 8337ba9189de188e2ed417018af2bf17a57d51ac
commit-date: 2024-06-12
host: x86_64-unknown-linux-gnu
release: 1.81.0-nightly
LLVM version: 18.1.7

compilation is also quite slow on 1.79.0 stable, using RUSTC_BOOTSTRAP=1 cargo rustc -p fayalite -- -Z time-passes:

time:  24.300; rss:  389MB ->  768MB ( +379MB)  MIR_borrow_checking
time:  21.751; rss:  768MB ->  958MB ( +191MB)  MIR_effect_checking

[veera-sivarajan]

@rustbot label -needs-triage +I-slow +A-mir +A-borrow-checker +T-compiler

[oli-obk]

can you simplify this to a single crate that reproduces your issue? then we can run rustc-perf on it and see which queries are actually at fault, since -Ztime-passes is very coarse in its grouping and can include a lot of trait solving and const eval time

[ashi009]

@oli-obk we have a crate that spends ~30s on MIR_borrow_checking. Although I can't share the code, I'd love to collect some data to debug this.

Could you share some pointers on what to check next?

All three of them are checks against really simple async fns:

#[async_trait::async_trait]
pub trait SomeAPI: Send + Sync {
    async fn perform_action(&self, action: SomeRequest) -> Result<SomeResult>;
}

#[async_trait::async_trait]
impl SomeApi for SomePtr {
    async fn perform_action(&self, action: SomeRequest) -> Result<SomeResult> {
        self.some_perform_action_impl(action).await
    }
}

and one of the type_op_prove_predicate has the following arg:

Canonical { value: ParamEnvAnd { param_env: ParamEnv { caller_bounds: [Binder { value: OutlivesPredicate('^1_0, '^1_1), bound_vars: [] }, Binder { value: OutlivesPredicate(state::engine::SomePtr, '^1_1), bound_vars: [] }], reveal: UserFacing }, value: ProvePredicate { predicate: Binder { value: TraitPredicate(<std::pin::Pin<std::boxed::Box<{async block@src/state/engine_api.rs:45:5: 45:53}>> as std::ops::CoerceUnsized<std::pin::Pin<std::boxed::Box<dyn futures::Future<Output = std::result::Result<...::SomeResult, ...::SomeError>> + std::marker::Send>>>>, polarity:Positive), bound_vars: [] } } }, max_universe: U0, variables: [CanonicalVarInfo { kind: Region(U0) }, CanonicalVarInfo { kind: Region(U0) }, CanonicalVarInfo { kind: Region(U0) }, CanonicalVarInfo { kind: Region(U0) }, CanonicalVarInfo { kind: Region(U0) }, CanonicalVarInfo { kind: Region(U0) }, CanonicalVarInfo { kind: Region(U0) }, CanonicalVarInfo { kind: Region(U0) }], defining_opaque_types: [] }

[oli-obk]

unfortunately, without a reproduction that we can run ourselves we can't even know if they are the same issues or different issues with the same symptoms. if you can minimize your private crate to something you can share, that would be great!