id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,focuses 45804,Make WP_Hook gather callback performance information,Rarst,,"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.",enhancement,new,normal,Awaiting Review,Plugins,,normal,,,,performance