Support running profile against other WP CLI commands about profile-command HOT 7 CLOSED

It would be pretty sweet if I could do:

As it turns out, you can!

1. Create a PHP file to execute

$ cat media-regenerate.php
<?php
WP_CLI::runcommand( 'media regenerate --yes', array( 'launch' => false ) );

2. Profile PHP file execution

$ wp profile eval-file media-regenerate.php
Found 1 image to regenerate.
1/1 Regenerated thumbnails for "download" (ID 7).
Success: Regenerated 1 of 1 images.
+---------+------------+-------------+-------------+------------+--------------+--------------+---------------+
| time    | query_time | query_count | cache_ratio | cache_hits | cache_misses | request_time | request_count |
+---------+------------+-------------+-------------+------------+--------------+--------------+---------------+
| 0.9374s | 0.0284s    | 6           | 88.68%      | 47         | 6            | 0s           | 0             |
+---------+------------+-------------+-------------+------------+--------------+--------------+---------------+

from profile-command.

I don't think the above result is correct. It doesn't show any internal profiling data (like the query count and time), it seems to only do what a basic time would do: diff the start and end times.

from profile-command.

Oops. I forgot to keep the current process.

I've updated my comment to include:

WP_CLI::runcommand( 'media regenerate --yes', array( 'launch' => false ) );

from profile-command.

Hehe, this ties neatly into wp-cli/wp-cli#3890 :
It shouldn't be as easy to have completely different behavior (resulting in a bug) just because you forgot an obscure array argument.

from profile-command.

It shouldn't be as easy to have completely different behavior (resulting in a bug) just because you forgot an obscure array argument.

The behavioral difference occurs because WP_CLI::runcommand()'s default behavior is to launch a new process. In order to track queries, etc., wp profile needs access to the $wpdb variable of the process, which it doesn't have when a new process is launched.

Technically speaking, the original result was correct, because no queries occurred in the current process.

Could you explain how wp-cli/wp-cli#3890 would've caught this? I think it's reasonable to have default behavior for methods, and optional arguments to change the behavior.

from profile-command.

I think it should be obvious from either the method or the arguments what the expected behavior is. So, in the above example, a very simple disambiguation would be to either require the 'launch' argument, or to have different methods for these very different behaviors, like run_command_in_same_process and run_command_in_new_process (I know, not the catchiest method names).

The point is that the intent should be clear and unambiguous. Providing default fallback values is nice for situations where it's mostly just about convenience. But in this particular case, runcommand is actually a facade to an entire category of methods, and they are chosen based on array arguments, which are neither validated nor checked in any other way. The default fallback values actually choose which specific type of functionality to run whenever you didn't provide overrides.

from profile-command.

I've left a comment on the linked issue.

from profile-command.