Principe de fonctionnement

Headstart repose sur deux patchs : -Zearly-metadata intégré à rustc et -Zheadstart ajouté à cargo. Le compilateur sépare l’analyse en deux phases : d’abord la vérification des interfaces (signatures, types publics) puis l’inspection des corps de fonctions. Dès que l’interface est validée, rustc écrit un fichier .early-rmeta contenant uniquement les métadonnées nécessaires à la compilation des crates dépendantes. Cargo, informé de la disponibilité de ce fichier, lance immédiatement les crates qui en dépendent, même si le producteur de métadonnées n’a pas encore fini d’analyser les corps. Le travail en cours libère son slot de thread, ce qui permet à d’autres tâches de s’exécuter en parallèle. Lorsque le fichier complet .rmeta est produit, il remplace l’early‑metadata et la génération de code reprend.

RUSTC=/path/to/headstart/rustc/build/host/stage1/bin/rustc \
/path/to/headstart/cargo/target/release/cargo check -Zheadstart

Performances mesurées

Les benchmarks présentés dans le dépôt couvrent treize projets réels (rust‑analyzer, zed, bevy, lemmy, polars, etc.). Sur une machine à 16 cœurs, cargo check gagne jusqu’à 54 % de rapidité, tandis que cargo build est accéléré de 42 %. Aucun des projets n’est plus lent. Avec le front‑end parallèle (-Zthreads=8), l’amélioration maximale atteint 25 %. Sur des configurations plus modestes (4 cœurs), rust‑analyzer voit son temps de vérification diminuer de 24 % et son temps de construction de 13‑15 %. Le crate codex‑rs bénéficie d’une réduction de 14 % du temps de cargo check. Ces gains proviennent essentiellement de l’utilisation de cœurs qui resteraient inactifs pendant l’attente des métadonnées complètes.

Implications et limites

Le principal coût de la technique est une hausse de la consommation mémoire, car les crates en aval conservent leurs propres analyses pendant que la dépendance finalise ses corps. De plus, le travail effectué sur les corps de fonctions peut être abandonné si la dépendance échoue ; le système signale alors l’erreur avec les mêmes diagnostics et le même code de sortie que l’approche traditionnelle, mais le message apparaît légèrement plus tard dans le flux JSON. Aucun changement n’est introduit dans la sémantique du code : le binaire final reste identique, les tests de swap de métadonnées confirment l’équivalence à tous les niveaux d’optimisation. La solution nécessite l’utilisation de versions patchées de rustc et cargo, activées via les variables d’environnement ou le fichier .cargo/config.toml. À ce jour, les patchs n’ont pas encore été intégrés dans les branches officielles du compilateur, ce qui limite leur adoption à des environnements de développement contrôlés.