I have some numbers lark, but they seem crazy (compare the plain debug and release builds).
Sorry for the presentation, but there’s too many numbers and I’m not sure how to show them properly.
# cargo build 1176.61s user 88.65s system 879% cpu 2:23.93 total
touch src/main.rs
# cargo build 4.01s user 1.82s system 100% cpu 5.815 total
find . -name '*.rs' | xargs touch
# cargo build 20.69s user 6.73s system 122% cpu 22.452 total
# cargo build --release 1055.34s user 62.75s system 807% cpu 2:18.53 total
touch src/main.rs
# cargo build --release 1.76s user 0.50s system 101% cpu 2.222 total
find . -name '*.rs' | xargs touch
# cargo build --release 418.70s user 13.84s system 618% cpu 1:09.97 total
# CARGO_BUILD_PIPELINING=true cargo build 1180.08s user 93.53s system 981% cpu 2:09.72 total
touch src/main.rs
# CARGO_BUILD_PIPELINING=true cargo build 9.65s user 2.19s system 100% cpu 11.825 total
time CARGO_BUILD_PIPELINING=true cargo build
# CARGO_BUILD_PIPELINING=true cargo build 20.84s user 6.72s system 135% cpu 20.384 total
# CARGO_BUILD_PIPELINING=true cargo build --release 1302.40s user 80.71s system 1251% cpu 1:50.51 total
touch src/main.rs
# CARGO_BUILD_PIPELINING=true cargo build --release 1.25s user 0.42s system 102% cpu 1.639 total
find . -name '*.rs' | xargs touch
# CARGO_BUILD_PIPELINING=true cargo build --release 559.51s user 20.39s system 1322% cpu 43.861 total
Another data point, which matches the expectations: I ran this for volta and these were the results:
$ hyperfine \
--prepare 'cargo +nightly build --all && fd ".*.rs" | xargs touch' \
'cargo +nightly build --all --release' \
'env CARGO_BUILD_PIPELINED=true cargo +nightly build --all --release'
Benchmark #1: cargo +nightly build --all --release
Time (mean ± σ): 20.924 s ± 0.803 s [User: 90.686 s, System: 2.266 s]
Range (min … max): 20.243 s … 22.306 s 10 runs
Benchmark #2: env CARGO_BUILD_PIPELINED=true cargo +nightly build --all --release
Time (mean ± σ): 20.601 s ± 0.584 s [User: 90.473 s, System: 2.216 s]
Range (min … max): 20.145 s … 21.903 s 10 runs
Summary
'env CARGO_BUILD_PIPELINED=true cargo +nightly build --all --release' ran
1.02 ± 0.05 times faster than 'cargo +nightly build --all --release'
I ran it in a variety of modes, and all came out like this: effectively no change. We have a couple internal libraries, but there’s nothing like syn in the mix, so it just doesn’t really affect things in this case. It basically doesn’t matter. And again, that’s exactly as expected given the dynamics of the codebase; I was not surprised at the outcome.
Ran this on a private code base that has about 268 dependencies, using a 6-core, 12 threads Intel i7-8750H on Windows 10. I’ll try to report back with incremental compilation time numbers when I get a chance.
I try build.pipelined = true in ~/.cargo/config and CARGO_BUILD_PIPELINED=true environment variable, but debug build time is the same: 42.79s with pipeline and 43.25s.
Is any way to see that pipeline option is really activated? Somewhere in CARGO_LOG=debug or anywhere?
Running cargo build --release I got 5m 48s without pipelining and 6m 05s with, but I don’t really trust these measurements because my laptop went into thermal throttling.
In other words, @alexcrichton, is it CARGO_BUILD_PIPELINING (as I assume) or CARGO_BUILD_PIPELINED? You mention both in the first post (also in the .cargo/config file). I suspect that some of the negative results posted here should be taken with a grain of salt.
By the way, may be the idea is the same as for drug test.
The first group of sick persons get real drug,
the second group no drugs, and the third get fake drug (placebo), but they think that this is real drug.
I guess the really big gains would come if we switched from timestamp-based to content-based caching, where this would allow us to get cache hits on a crate if its dependencies only changed in implementation and not interface (which presumably is roughly what the metadata file contains)?
For the pants engine at sha 5f2d91d8, 8 cores / 16 hyperthreads:
