rustc final stages extremely slow for large programs, with msvc builds (1.89)

I tried this code:

https://github.com/zed-industries/zed

I expected to see this happen: Build time is approximately linearly scaled with program size/complexity

Instead, this happened: Build time for this program has been getting really really long (like 21 minutes on a 3950x).

Meta

rustc --version --verbose:

rustc 1.89.0 (29483883e 2025-08-04)
binary: rustc
commit-hash: 29483883eed69d5fb4db01964cdf2af4d86e9cb2
commit-date: 2025-08-04
host: x86_64-pc-windows-msvc
release: 1.89.0
LLVM version: 20.1.7

The main problem appears to be near the final stages of compilation. All of the dependency crates have been completed. As an example if you repeat the classic windows problem of prevent the final output (zed.exe in this case) from being written (by e.g. having a copy running), and then restart the build, the work that is restarted to produce this final artifact is extremely slow (Finished release profile [optimized + debuginfo] target(s) in 21m 41s).

Attaching with the visual studio profiler reveals time being sent in basic_string allocation (it's a messy symbol that likely has a lot of inlining, but it's coming from Construct_n basic_string char_traits std allocator, underneath a frame containing rustc_codegen_llvm. For a snapshot of several minutes of this build time 60% of the CPU time was being spent in basic_string alloc.

I don't immediately have to hand a build for which I can get much more precise symbols, but I will be happy to help when I have more time. I suspect though this is fairly easy to reproduce, and the same target takes ~7m from full cold build on a mac of similar compute power.

Start by reproducing the Zed release build on Windows MSVC with rustc 1.89, focusing on the final artifact stage after dependencies finish. Profile the rustc_codegen_llvm path and basic_string allocation, then compare the blocked-output rerun with the reported cold build. Done means identifying and addressing the cause of the excessive final-stage time, with evidence from a repeatable benchmark.