-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Description
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.