Add hooks to be run before and after each callback

[pento]

Since before the dawn of time, debugging tools have relied on the all hook to collect information about how long hooks take to run, and which callbacks are registered to that hook.

This has a few drawbacks. Primarily, it's not possible to collect timing information about individual callbacks, and it's quite difficult to manage recursive hook behaviour.

With that in mind, hooks that run before and after each callback would be quite valuable, but they do need to be considered carefully.

• What kind of performance impact would they have? If there are no callbacks registered to these hooks, there should ideally be no performance impact.
• Should they be WP_DEBUG only? This would discourage plugins from abusing them on production systems - they would only be used if the site admin explicitly sets the site to debugging mode.
• Dealing with recursion is fun, should they provide any helpers for indicating recursion level, or is it up to the code hooking into them to handle that?

[CodeBard]

Most important, most necessary. Im debugging a wordpress/woocommerce install which has ~15 seconds time in init action. If we had something like this, it would be very easy to determine which of the 90~ callbacks hooked to init is causing slowness.

[johnbillion]

Aside: It is actually possible to add such timing to hooks without a before and after hook, it's just nasty.

runcommand's ​wp profile package does this, and ​Query Monitor will support it in a future version.

[johnbillion]

#41728 was marked as a duplicate.

[johnjamesjacoby]

I think this is a great idea.

What kind of performance impact would they have? If there are no callbacks registered to these hooks, there should ideally be no performance impact.

Likely near-zero impact.

Should they be WP_DEBUG only? This would discourage plugins from abusing them on production systems - they would only be used if the site admin explicitly sets the site to debugging mode.

I think not having them be WP_DEBUG-only allows tricky problems to be investigated in production environments, where they are the most likely to be noticed.

Dealing with recursion is fun, should they provide any helpers for indicating recursion level, or is it up to the code hooking into them to handle that?

Up to the code hooking in, I think.

@johnbillion were you implement this in Query Monitor?