[wp-trac] [WordPress Trac] #45804: Make WP_Hook gather callback performance information

[WordPress Trac]

#45804: Make WP_Hook gather callback performance information
-------------------------+-----------------------------
 Reporter:  Rarst        |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:  trunk
 Severity:  normal       |   Keywords:
  Focuses:  performance  |
-------------------------+-----------------------------
 The Hook API represents one of the most interesting parts of core from
 performance point of view. It is both widely used and implementation is in
 userland code, as opposed to language features (such as standalone
 function calls).

 However as of current implementation (`WP_Hook` class) it is a huge
 challenge to gather profiling information from it in safe and compatible
 way. Class itself is `final` and instances cannot be effectively replaced.
 Injecting custom logic at `all` hook and reimplementing hook execution in
 extension code is possible, but risky.

 I suggest we implement `WP_Hook` natively logging origin and duration
 times for executed callbacks. The information can be added to callback
 record which is in public access space and will not cause any backwards
 incompatible changes.

 My draft suggestion would be something like this (notably to account for
 multiple executions of hook/callback):

 {{{
 [
         'function' => ...
         'accepted_args' => ...
         'runs' => [
                 [ 'start' => ..., 'duration' => ... ],
                 [ 'start' => ..., 'duration' => ... ],
                 [ 'start' => ..., 'duration' => ... ],
         ]
 ]
 }}}

 Main concern would be resource cost, with sites possibly calling tens of
 thousands of hooks. I think resource overhead should be reasonable with
 only adding two floats to array and no complex calls or calculations. This
 can be tested and profiled on a proof of concept implementation.

 The possible mitigation to runtime costs can be making the feature opt–in
 with flag analogous to `SAVEQUERIES`, for example `SAVE_HOOK_TIME`.

 The possible mitigation to memory costs can be implementing cut off limit
 to amount of timings stored, e.g. start discarding old records when a
 certain limit of X records is reached for a callback.

 If there is agreement on feasibility I will work on a patch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45804>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform