Activate preprocessor cache mode by default

[Alphare]

Preprocessor cache mode (or "direct mode" in ccache speak), offers a measurable improvement for C/C++ caching.

A non-scientific test of compiling Firefox on a Ryzen 7950x with hot caches saw this mode changing the wall time from ~48s to ~13s. This is the overall time spent in mach build with the only work needed is to recompile all C++, kinda like so:

$ mach build
[...]
$ fd '\.o$' obj-* | xargs rm && time ./mach build

As noted in the docs, this applies only to local storage.

[codecov-commenter]

Codecov Report

Attention: 34 lines in your changes are missing coverage. Please review.

Comparison is base (71a528f) 29.99% compared to head (86b1a39) 30.54%.

Files	Patch %	Lines
src/compiler/compiler.rs	59.45%	0 Missing and 15 partials ⚠️
tests/system.rs	40.90%	7 Missing and 6 partials ⚠️
src/compiler/preprocessor_cache.rs	0.00%	0 Missing and 2 partials ⚠️
src/compiler/rust.rs	83.33%	0 Missing and 2 partials ⚠️
src/test/tests.rs	0.00%	0 Missing and 1 partial ⚠️
tests/harness/mod.rs	66.66%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1951      +/-   ##
==========================================
+ Coverage   29.99%   30.54%   +0.55%     
==========================================
  Files          51       51              
  Lines       19153    19191      +38     
  Branches     9222     9234      +12     
==========================================
+ Hits         5744     5861     +117     
+ Misses       7961     7761     -200     
- Partials     5448     5569     +121     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Alphare]

It looks like there is a test failure only with ubuntu-20.04 and windows, but not ubuntu-22.04 and others, regardless of Rust version.

I have currently no real idea why that happens, and no way of reproducing outside of the CI. I'll have to come back to this later. In the meantime if anyone has an idea, I'd be grateful.

[sylvestre]

@glandium do you know what is going on?

---- test_sccache_command::with_preprocessor_cache stdout ----
cargo:rerun-if-env-changed=CC_x86_64-pc-windows-msvc
CC_x86_64-pc-windows-msvc = None
cargo:rerun-if-env-changed=CC_x86_64_pc_windows_msvc
CC_x86_64_pc_windows_msvc = None
cargo:rerun-if-env-changed=HOST_CC
HOST_CC = None
cargo:rerun-if-env-changed=CC
CC = None
cargo:rerun-if-env-changed=CFLAGS_x86_64-pc-windows-msvc
CFLAGS_x86_64-pc-windows-msvc = None
cargo:rerun-if-env-changed=CFLAGS_x86_64_pc_windows_msvc
CFLAGS_x86_64_pc_windows_msvc = None
cargo:rerun-if-env-changed=HOST_CFLAGS
HOST_CFLAGS = None
cargo:rerun-if-env-changed=CFLAGS
CFLAGS = None
cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
CRATE_CC_NO_DEFAULTS = None
CARGO_CFG_TARGET_FEATURE = None
get server stats: ServerInfo { stats: ServerStats { compile_requests: 1, requests_unsupported_compiler: 0, requests_not_compile: 0, requests_not_cacheable: 0, requests_executed: 1, cache_errors: PerLanguageCount { counts: {}, adv_counts: {} }, cache_hits: PerLanguageCount { counts: {"C/C++": 1}, adv_counts: {"c [msvc]": 1} }, cache_misses: PerLanguageCount { counts: {}, adv_counts: {} }, cache_timeouts: 0, cache_read_errors: 0, non_cacheable_compilations: 0, forced_recaches: 0, cache_write_errors: 0, cache_writes: 0, cache_write_duration: 0ns, cache_read_hit_duration: 1.0582ms, compiler_write_duration: 0ns, compile_fails: 0, not_cached: {}, dist_compiles: {}, dist_errors: 0 }, cache_location: "Local disk: \"C:\\\\Users\\\\runneradmin\\\\AppData\\\\Local\\\\Mozilla\\\\sccache\\\\cache\"", cache_size: Some(6202), max_cache_size: Some(10737418240), use_preprocessor_cache_mode: true, version: "0.7.1" }
thread 'test_sccache_command::with_preprocessor_cache' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `1`', tests\system.rs:189:9
stack backtrace:

[glandium]

In the windows logs, this is not good omens:

sccache: Starting the server...
sccache: error: Timed out waiting for server startup

In the Ubuntu logs, this is not good omens either:

test test_sccache_command::with_preprocessor_cache has been running for over 60 seconds

I was able to reproduce locally in a Ubuntu 20.04 chroot, and it seems sccache is stuck during the test... which in fact, is reproducible with unmodified 0.7.1:

$ touch test.c
$ SCCACHE_DIRECT=true sccache gcc -o test.o -c test.c

With a foreground sccache server, this is what appears in the output:

thread 'tokio-runtime-worker' panicked at src/compiler/c.rs:687:37:
source slice length (3) does not match destination slice length (2)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

... for which I'm going to send a PR.

[glandium]

#1962

This is probably not going to help on Windows, though...

[glandium]

(Note, it would be good to have tests to validate these code paths)

[glandium]

#1962

This is probably not going to help on Windows, though...

#1964 fixes Windows.

[glandium]

I'll add this comment here for future work, after seeing the output from --stop-server while debugging the issues with this PR: IIRC ccache shows the number of cache hits that went through direct mode vs. non direct mode, we may want to do that too, rather than only showing that direct mode is enabled.

[Alphare]

Thanks for the fixes @glandium :)