You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Avoid the extra PHP process in the wp launcher #389
The wp launcher script starts PHP twice for every command: once to run php -r "echo PHP_OS;", which is only needed to detect Cygwin, and once to run WP-CLI itself. Together with the shell wrappers this adds about 30 ms to every call (121 ms versus 92 ms for wp cli version locally).
The test suites make well over 10,000 wp calls per run of the bundled commands, so this adds up to several minutes for each CI configuration. It also slows down every real-world invocation.
The fix belongs in bin/wp in wp-cli/wp-cli. It is tracked here because the test suite is where the impact is largest.
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.
Measured on GitHub Actions with the full test matrix of core-command and cache-command, run on measure/* 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 using wp-cli/wp-cli from wp-cli/wp-cli#6442 instead of its main branch.
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-command and about ±5% for core-command. All runs executed the same scenarios (about 4,518 for core-command and 1,162 for cache-command across the Linux jobs).
This is the clearest gain so far: about 12% for cache-command, whose scenarios consist almost entirely of short wp calls, and about 8% per job for core-command (-2.4% in total, which the noise of that package can hide). It also saves a PHP process for every wp command run outside of the tests.
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 usingwp-cli/wp-clifrom wp-cli/wp-cli#6442 instead of itsmainbranch.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 jobThis is the clearest gain so far: about 12% for
cache-command, whose scenarios consist almost entirely of shortwpcalls, and about 8% per job forcore-command(-2.4% in total, which the noise of that package can hide). It also saves a PHP process for everywpcommand run outside of the tests.