Research: Reduce Build Times with sccache

[josecelano]

Goal

Research whether sccache is effective for this workspace in local development and on GitHub-hosted CI runners, and decide if it should be adopted fully, partially, or not at all.

This is an evidence-driven research issue. No workflow changes are assumed until benchmarks confirm a measurable benefit.

Background

A benchmark on 2026-05-01 shows a clean build takes ~142 s, of which ~89 % is compilation.

• Swatinem/rust-cache appears ineffective at this workspace size (~9 GB target/; transfer cost exceeds compile time).
• sccache caches individual codegen units by content hash, so a single changed crate does not bust the whole cache.

Known limitations to validate:

• bin, dylib, cdylib, and proc-macro crates are never cached by sccache (the heaviest crate torrust-tracker is a bin).
• Incremental compilation must be disabled (CARGO_INCREMENTAL=0).
• GitHub-hosted runners are non-sticky; every run starts cold from remote cache.

The full issue spec, benchmark data, and task breakdown are in docs/issues/<issue-number>-reduce-build-times-sccache/ in the repository.

Tasks

1. Local A/B benchmark (baseline vs sccache, cold/warm/warm-after-change).
2. Decide whether to enable sccache in .cargo/config.toml for developers.
3. CI A/B benchmark on GitHub-hosted runners (first and repeat runs).
4. Document recommendation: adopt, hybrid, or reject.