Repository navigation
Lower the cost of each launched wp process #385
Description
Almost all of the suite's run time is spent in the wp processes the scenarios launch; the Behat process itself accounts for about 3% of a run. Each wp call costs about 0.3 seconds, and the bundled commands make around 9,300 of them per suite run, plus the ones the framework makes itself.
Two things make each process more expensive than it needs to be:
- Xdebug. When Xdebug is loaded locally, every child process pays for it. Turning it off for the launched processes took a local
cache-commandrun from 126 to 98 seconds. It should stay off unless coverage is collected or step debugging is requested (see Enable Xdebug in Behat tests #257). - No opcode cache. Every process compiles WP-CLI and the package code from scratch, although that code does not change during a run. Caching only that code took a typical call from about 300 to 200 ms locally. The per-scenario WordPress copies must stay uncached: they are rewritten during scenarios, and a stale compiled file would change what a test exercises.
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 #401.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 jobOn CI, the difference is within the noise. Xdebug is only installed for the coverage job there, so only the opcode cache applies, and the PHP runners have opcache loaded with
opcache.enable_clioff. A second pair of runs with the run time report enabled (baseline and #401 forcore-command, baseline and #401 forcache-command) shows the average process taking about 3% less time (median over all jobs), against about 33% locally. On the runners, compiling the framework code is evidently a much smaller share of eachwpcall.Locally, where Xdebug is loaded, a full
cache-commandrun went from 126 to 98 seconds with Xdebug off for the launched processes alone. So this mainly helps local runs, and is not worth it for CI on its own.