Incremental causes significant regression in clean compile time for winapi #48247
Comments
retep998
added
I-compiletime
pietroalbini
added
the
C-enhancement
|
I believe we by-default disable incremental compilation for any non-local (so, non-path, I believe) dependencies so this at least shouldn't affect downstream users of winapi. Still bad though. |
|
Yes, Cargo builds non-local dependencies in non-incremental mode, so clients of winapi should not hit this case. This is still an interesting data point. Is the crate a single big module? |
|
|
|
Huh, why is it compiling to just one object file in incremental mode then? Do all except one module only contain |
|
Because all the functions are ; ModuleID = 'winapi0-44883cb3741bc93bb95d7fd494a16a2c.rs'
source_filename = "winapi0-44883cb3741bc93bb95d7fd494a16a2c.rs"
target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc"
!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!3, !4}
!0 = distinct !DICompileUnit(language: DW_LANG_Rust, file: !1, producer: "clang LLVM (rustc version 1.25.0-nightly (3d292b793 2018-02-03))", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2)
!1 = !DIFile(filename: "src\5Clib.rs", directory: "C:\5CUsers\5CPeter\5CCode\5Cwinapi-rs")
!2 = !{}
!3 = !{i32 2, !"CodeView", i32 1}
!4 = !{i32 2, !"Debug Info Version", i32 3} |
|
How are re-compilation times after making a small change? |
|
And what is the exact version of |
|
https://gist.github.com/retep998/83dda0b6f720bce554a32e859d09f0bb An incremental rebuild after a null edit is 17.99 while a non-incremental rebuild after a null edit is 18.47. |
Wow! That's certainly not good. Is there a way to compile |
|
Of course. Just acquire the relevant |
|
@Mark-Simulacrum, we should look into adding |
|
Yes, I've wanted to do it for a long time (as has @retep998) but have never quite found the time. Hopefully soon! |
jonas-schievink
added
the
T-compiler
|
Status update, this is still an issue. Using latest nightly. |
|
With rustc 1.76.0-beta.3 (3a3478e 2024-01-10): From scratch builds:
Incremental re-compile after touch src/lib.rs takes: 7.2s So seems like incremental still makes things slower (or isn't a win at all), but we're significantly faster and/or I'm using better hardware (Ryzen 3950x). After the first build it's only 200ms slower on incremental re-compiles, which to me indicates that the underlying problem here is fixed - we expect the incremental, but no cache, scenario to be slower and this is represented in ~all perf.r-l.o benchmarks. Closing as fixed. |
Doing
cargo rustc --features everything -- -Ztime-passeswithwinapi0.3.tl;dr clean incremental is dramatically slower than clean normal, for minimal gains in rebuild times.
Times taken using
rustc 1.28.0-nightly (b68432d56 2018-06-12)Clean incremental: 34.68s
Rebuild incremental: 19.59s
Clean normal: 23.48s
Rebuild normal: 22.73s
A clean incremental build
A clean non-incremental build (
CARGO_INCREMENTALset to0)The text was updated successfully, but these errors were encountered: