Skip to content

Performance regression in 1.72 related to normalization of opaques with late-bound vars #115283

@kornelski

Description

@kornelski
Contributor

Upgrade from 1.71 to 1.72 has made compilation time of my async-heavy actix server 350 times slower (from under 5s to 30 minutes, on a 32GB M1 Max CPU).

I've bisected it to commit a20a04e (#113108).

The slowdown is still in the latest nightly (1.74.0 69e97df 2023-08-26). 1.72 and the nightly spend 30% of all compilation time in Interners::intern_ty, mainly called by <rustc_middle[b15c2eca62e7285b]::ty::Ty as rustc_type_ir[f43ddb3fb00a443c]::fold::TypeSuperFoldable<rustc_middle[b15c2eca62e7285b]::ty::context::TyCtxt>>::try_super_fold_with::<rustc_middle[b15c2eca62e7285b]::ty::generic_args::ArgFolder> and <rustc_middle[b15c2eca62e7285b]::ty::Ty as rustc_type_ir[f43ddb3fb00a443c]::fold::TypeSuperFoldable<rustc_middle[b15c2eca62e7285b]::ty::context::TyCtxt>>::try_super_fold_with::<rustc_trait_selection[961e83e42176765a]::traits::project::AssocTypeNormalizer>.

The reduced code is in: https://gitlab.com/lib.rs/main/-/commits/reproducer

outdated info Apologies for a big spaghetti reproducer. Let me know if it'd be useful to reduce it.
git clone --recursive https://gitlab.com/lib.rs/main
cd main
git reset --hard 81c612b
cargo build -p crates-server

I suspect the culprit is this function, which is used in several places in server/src/main.rs:

async fn with_file_cache<F: Send>(state: &AServerState, cache_file_name: &str, cache_time: u32, allow_stale: bool, generate: F) -> Result<Rendered, anyhow::Error>
    where F: Future<Output=Result<Rendered, anyhow::Error>> + 'static {

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

Activity

added
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.
and removed
regression-untriagedUntriaged performance or correctness regression.
on Aug 27, 2023
compiler-errors

compiler-errors commented on Aug 27, 2023

@compiler-errors
Member

Yeah, I'd appreciate if you could minimize it. @Dirbaio helped me with a similar regression that was fixed in #114948, so I wonder if there's some other missing normalization that needs to be added somewhere...

compiler-errors

compiler-errors commented on Aug 27, 2023

@compiler-errors
Member

In the mean time, I'll try to look at the flamegraphs for the code you shared...

compiler-errors

compiler-errors commented on Aug 27, 2023

@compiler-errors
Member

@kornelski: Is there another step I need to do in this build? 😅

error: couldn't read front_end/src/../../style/public/critical.css: No such file or directory (os error 2)
   --> front_end/src/front_end.rs:101:53
    |
101 |         let data = self.critical_css_data.unwrap_or(include_str!("../../style/public/critical.css"));
    |                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

kornelski

kornelski commented on Aug 27, 2023

@kornelski
ContributorAuthor

Thank you for checking it out — sorry about the build error. I though I removed all of these. CSS is irrelevant here, can be an empty string.

https://gitlab.com/lib.rs/main/-/commits/reproducer

compiler-errors

compiler-errors commented on Aug 28, 2023

@compiler-errors
Member

I'm finding several main sources of slowness here:

  1. Monomorphization causing us to repeatedly normalize opaques that show up in MIR bodies -- enable RevealAll pass always #115299 causes the compile time to go from 28 minutes to 11 minutes, for example.
  2. We're repeatedly checking FnOnce obligations for the FnDef1 types of async fns. This leads us to repeatedly compute the signatures of these async fns and then normalize their output futures over and over again.

Footnotes

  1. The ZST corresponding to each function item.

apiraino

apiraino commented on Aug 29, 2023

@apiraino
Contributor

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

added
P-highHigh priority
and removed
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
on Aug 29, 2023

33 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.I-compiletimeIssue: Problems and improvements with respect to compile times.P-mediumMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.WG-compiler-performanceWorking group: Compiler Performanceregression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @kornelski@pnkfelix@lqd@wesleywiser@compiler-errors

        Issue actions

          Performance regression in 1.72 related to normalization of opaques with late-bound vars · Issue #115283 · rust-lang/rust