Repository navigation
Trim fixed per-scenario overhead #388
Description
A few fixed costs are paid by every scenario, or by every scenario of a kind, without contributing to what is tested:
- Removing the scenario's
RUN_DIR(about 3,800 files for a WordPress install) blocks the next scenario for about 50 ms. It can happen in the background once the directory is moved out of the way. - Starting a background process (
I launch in the background, the PHP built-in web server) always waits a full second before checking that the process is alive, even when it is ready much sooner.
Across all bundled commands, this adds up to roughly 2 to 3 minutes for each CI configuration.
Measuring: take the baseline from #384, then open a draft PR, run the same CI jobs against it and record both results here before we decide.
Activity
schlessera commentedon Oct 30, 2026
Measurement
Measured on GitHub Actions with the full test matrix of
core-commandandcache-command, run onmeasure/*branches of wp-cli/core-command#350 and wp-cli/cache-command#137. All runs use wp-cli-tests at the same base commit (9298472) and differ only in the changes of #403.The metric is the Behat wall time of each job, from the start of the Behat step to its last summary, for the 49 Linux jobs present in all runs. "Total" is the sum over these jobs, "per job" the median of each job's change against the mean of the two baseline runs. Both baselines run the identical code, so their spread is the noise level: about ±1% for
cache-commandand about ±5% forcore-command. All runs executed the same scenarios (about 4,518 forcore-commandand 1,162 forcache-commandacross the Linux jobs).core-commandtotalcore-commandper jobcache-commandtotalcache-commandper jobBoth packages got faster, by about 10% for
core-commandand about 3 to 4% forcache-command, beyond the noise of both. The one failed job in thecore-commandrun is the Windows job, where Chocolatey timed out installing Ghostscript before any scenario ran.