Rendre le coût en fichiers visible, et le réduire sans rien retirer par défaut

[Beennnn]

Pourquoi

Le nombre de fichiers décide de ce qu'une campagne coûte là où un filtre de sécurité inspecte chaque ouverture — et il n'était visible nulle part. Pour le connaître il fallait aller compter à la main, sur la machine où compter est justement lent : donc jamais. Un réglage qui le réduit existait, documenté, et rien dans la sortie de l'outil n'y menait.

Le modèle de coût a été mesuré avant qu'on en tire quoi que ce soit : une latence fixe injectée sur chaque ouverture sous le répertoire de sortie donne un total qui suit une ouverture par fichier écrit. Le temps payé est donc le nombre de fichiers multiplié par la latence du filtre, et rien d'autre.

Ce qui est fait sans être demandé — parce que ça ne retire rien

• Le compte est dit. Passé dix mille fichiers, l'outil l'annonce en fin de campagne et nomme le répertoire à exclure ; diagnostic.json le porte exécution par exécution.
• Les deux sites sont rendus en même temps. Le rapport ciblé apprend du XML quelles classes ont tourné, donc la passe de données doit précéder — et elle emportait jusqu'ici le site complet, ce qui sérialisait les deux rendus. Scindée en trois passes, elle écrit deux fichiers et les rendus se recouvrent.
• Le rapport ciblé n'est plus écrit quand toutes les classes analysées ont tourné : il énumérerait alors exactement le complet. Le test est strict et fait sur la couverture seule — une classe jamais entrée, ou un paquet masqué que le CLI ignore et place dans le complet, le désactivent.

Mesures, sur l'étape de rendu

Latence par ouverture	Avant	Après
aucune	0,75 s	0,76 s	rien perdu — le démarrage en plus est payé par le recouvrement
5 ms	1,69 s	1,24 s	−27 %
10 ms	2,62 s	1,73 s	−34 %
20 ms	4,44 s	2,68 s	−40 %

Sur l'outil lui-même, lu aux horodatages des fichiers, la phase passe de 4,26 s à 2,45 s à 20 ms (−42 %). Rapporté à une exécution entière : 7,84 s → 7,22 s — le reste d'une exécution paie l'application, les composants et l'assemblage, que rien de ceci ne touche.

Ce qui restreint reste hors défaut, et porte son prix là où il se propose

Une section d'aide dédiée aux machines filtrées commence par l'exclusion de runs/, qui ne coûte rien, puis liste chaque réglage avec ce qu'il abandonne. FileCostTest la tient : une valeur ajoutée à JACOCO_REPORTS et oubliée là casse la construction.

• JACOCO_REPORTS=minimal — lâche aussi le rendu fusionné de la campagne, en gardant son XML et son CSV : la figure survit à son rendu.
• ARCHIVE=keep|replace — rassemble runs/ en une archive ; replace ne remplace l'arborescence qu'après avoir compté les entrées écrites contre les fichiers parcourus. Ce que replace retire est écrit noir sur blanc : les liens de la page vers les sites JaCoCo cessent de résoudre, --report-only et --serve n'ont plus de quoi reconstruire.

Un défaut trouvé en chemin

Le gabarit déclarait lang="fr" en portant de l'anglais depuis l'inversion. Le script le corrigeait au chargement, donc rien ne se voyait — mais le fichier tel qu'il est sur le disque annonçait le français à un lecteur d'écran et au premier rendu. Corrigé, avec le test qui le garde.

Vérifications

• 282 tests unitaires (15 nouveaux), Linux ; la CI passe aussi sous Windows.
• Recette locale : 63 contrôles, dont quatre nouvelles étapes — minimal par exécution, minimal sur la fusion, --archive, --archive replace.
• Couverture identique au chiffre près entre full, detailed, data et minimal ; 186 → 101 → 9 fichiers par exécution sur l'application d'exemple.
• Compter n'est pas gratuit non plus — un parcours ouvre chaque répertoire, 0,63 s sous un filtre à 20 ms : d'où le total pris une seule fois à la fin, et le diagnostic qui somme les exécutions qu'il vient de compter plutôt que de repasser dessus.

🤖 Generated with Claude Code

https://claude.ai/code/session_01J956wjynbd7fkZx4HpjHzP

---

Generated by Claude Code