Closed retep998 closed 9 months ago
cc @michaelwoerister
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?
winapi
has nearly 300 modules, but of widely varying size. There are some small modules with only couple definitions, and there are some rather large modules weighing in as much as 336KiB.
Huh, why is it compiling to just one object file in incremental mode then? Do all except one module only contain #[inline]
functions?
Because all the functions are #[inline]
functions (aside from extern functions which don't have associated bodies anyway), so there's literally nothing to codegen.
; 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 rustc
used for producing the timings above?
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.
rustc -vV
rustc 1.25.0-nightly (3d292b793 2018-02-03)
binary: rustc
commit-hash: 3d292b793ade0c1c9098fb32586033d79f6e9969
commit-date: 2018-02-03
host: x86_64-pc-windows-msvc
release: 1.25.0-nightly
LLVM version: 4.0
An incremental rebuild after a null edit is 17.99
Wow! That's certainly not good. Is there a way to compile winapi
on Linux so that we could add it as a benchmark to perf.rust-lang.org?
Of course. Just acquire the relevant x86_64-pc-windows-msvc
std component using rustup and then build winapi for that target. It's a trivial rlib so there's no cross C toolchain hassle to deal with. And don't forget to specify --features everything
.
@Mark-Simulacrum, we should look into adding winapi
as a benchmark. It seems to produce a workload that is quite different from most other crates.
Yes, I've wanted to do it for a long time (as has @retep998) but have never quite found the time. Hopefully soon!
Status update, this is still an issue. Using latest nightly.
Incremental Debug
Compiling winapi v0.3.8 (D:\a\winapi-rs\winapi-rs)
Finished dev [unoptimized + debuginfo] target(s) in 50.73s
Non-incremental Debug
Compiling winapi v0.3.8 (D:\a\winapi-rs\winapi-rs)
Finished dev [unoptimized + debuginfo] target(s) in 36.30s
Release
Compiling winapi v0.3.8 (D:\a\winapi-rs\winapi-rs)
Finished release [optimized] target(s) in 36.60s
With rustc 1.76.0-beta.3 (3a3478ec4 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-passes
withwinapi
0.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_INCREMENTAL
set to0
)