Compilation of large project taking much longer after 1.84 (monomorphization)

[lsunsi]

Code

I have a big private project and we try to stay current on rust versions. Upon trying 1.84 I saw compilation times grow about 3 times. I already seen this behavior in other rust versions which made me have to skip it, for example 1.82.

I self-profiled the compile in 1.83 and 1.84 and diffed, so I got to this (https://gist.github.com/lsunsi/7d301c7e332f50a734647d3aff0efbdc).
I'm not sure how useful it is, but there we go. I can post the prof data as well if it's useful.

Further, I'll try to bisect and get back with more information.

Version it worked on

It most recently worked on: 1.83

rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1

Version with regression

rustc --version --verbose:

rustc 1.84.0 (9fc6b4312 2025-01-07)
binary: rustc
commit-hash: 9fc6b43126469e3858e2fe86cafb4f0fd5068869
commit-date: 2025-01-07
host: x86_64-unknown-linux-gnu
release: 1.84.0
LLVM version: 19.1.5

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

[lqd]

While the bisection results as discussed in the other issue will be helpful, I'm sure you know this but we won't be able to do much without some code to reproduce and analyze the issue.

[lochetti]

@lqd, I work with @lsunsi.
I tried to use https://github.com/rust-lang/cargo-bisect-rustc to try to bisect and discover which commit between 1.83.0 and 1.84.0 could be the problem, but even the nightly that the cargo-bisect-rustc uses to try the start of the range (which is the nightly-2024-10-13 in that case) also takes the unusual long time to run cargo build.

Right now, I am thinking that because it uses a nightly instead of a "stable build" it does not really reproduces the same behaviour as if I was running cargo build with the 1.83.0-stable. Does it make any sense? The summary is that any nightly build that I try has the longer compilation time for our project.

Super thanks!

[lqd]

but even the nightly that the cargo-bisect-rustc uses to try the start of the range (which is the nightly-2024-10-13 in that case) also takes the unusual long time to run cargo build.

Here, you should try to go back further than 1.83.0 to see if the difference starts to appear at some earlier point.

Right now, I am thinking that because it uses a nightly instead of a "stable build" it does not really reproduces the same behaviour as if I was running cargo build with the 1.83.0-stable. Does it make any sense? The summary is that any nightly build that I try has the longer compilation time for our project.

Interesting. Normally this should be quite unusual, because nightlies and stable have basically the same code, only gated differently. You could try using the stable release but unlocking the gating so it behaves as a nightly. With the env var RUSTC_BOOTSTRAP=1 your stable release should "think it's a nightly".

If that behaves differently than the nightly that was promoted to 1.83.0 it will be quite strange. And if it behaves differently than without the env var, it will also be quite strange. Both cases would help you narrow down the source of the issue.

[jieyouxu]

And also the other way around, you could try RUSTC_BOOTSTRAP=-1 on the nightly to make it think it is a stable rustc, but I suspect that should not cause observable differences (outside of you can't use nightly features).