Zdůvodnění
Ručně udržovaný seznam benchmarků zastará v den, kdy se přidá příkaz, což je den, kdy cena nového příkazu zůstane neměřena. Registr povrch už zná, fixtury už popisují jeden scénář na příkaz a majordomus bench čte obojí, takže přidání příkazu přidá jeho benchmark bez dalšího kroku. Studený a teplý jsou různé fakty o příkazu: první běh po čerstvé instalaci a ustálený stav při teplém souborovém systému a shellu. Jeden průměr obou nepopisuje ani jeden.
Požadované chování
majordomus bench odvozuje své cíle z share/commands.yaml (každý veřejný příkaz kromě harnessu), své scénáře z test/fixtures/commands/<command>.json, když je sada přítomna, a pro každý cíl a režim zaznamenává počet, minimum, p50, p90, p95, p99, maximum, průměr a směrodatnou odchylku. Příkaz jen pro čtení se vzorkuje teplý v jednom repozitáři po jednom studeném běhu; příkaz, který mění stav, se vzorkuje studený v čerstvém repozitáři na každý vzorek a nemá teplé rozdělení. Běhy jsou lokální důkazy pod .ai/local/benchmarks/; baseline je baseline.json pod .ai/repo/benchmarks/, zapisovaný jen --write-baseline na čistém stromě; --check odmítne regresi přes prahy benchmark.regression politiky exit kódem.
Chování při selhání
bench končí s 12 pro cíl, který není veřejný příkaz, a s 13, když cíl neběží čistě, se jmenováním cíle a jeho stavu. Případ test/cases/79_bench_command.sh dokazuje, že seznam cílů sleduje mutaci registru a že distribuce jsou samostatné a úplné.
Ověření
bash test/run.sh 79_bench_command a majordomus bench --list proti majordomus doctrine list, když se přidá příkaz.