hanna-kruppe
commented
6 years ago cc @michaelwoerister
Closed retep998 closed 9 months ago
hanna-kruppe
commented
6 years ago cc @michaelwoerister
Mark-Simulacrum
commented
6 years ago 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.
michaelwoerister
commented
6 years ago 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?
retep998
commented
6 years ago 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.
michaelwoerister
commented
6 years ago Huh, why is it compiling to just one object file in incremental mode then? Do all except one module only contain #[inline] functions?
retep998
commented
6 years ago 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?
michaelwoerister
commented
6 years ago And what is the exact version of rustc used for producing the timings above?
retep998
commented
6 years ago 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.0An 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?
retep998
commented
6 years ago 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.
michaelwoerister
commented
6 years ago @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.
Mark-Simulacrum
commented
6 years ago Yes, I've wanted to do it for a long time (as has @retep998) but have never quite found the time. Hopefully soon!
retep998
commented
4 years ago 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.60sWith 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-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)