Speedier PHP Execution in WordPress 6.3

You can find more information in the Trac ticket, especially about the impact of another proposed improvement that we did, as an emphasis on the importance of cross-collaboration work.

In practice, however, it’s usually trickier, and optimizing things like this is not always straightforward. Though, there are several questions that we can ask ourselves that may assist:

• Where do we start?
  • What are the most frequently called functions?
  • What are the slowest functions?
  • What is the slowest behavior of the application in general?
• What are we optimizing, and at which layer?
  • App layer? HTTP layer? Code layer? Caching?
• How do we measure it?
• What are the trade-offs?
  • Resources: Do we trade space (how much memory it takes during execution) or time (how much time it takes to execute)? (Space and time is an interesting general philosophical concept)
  • What is the impact of the proposed improvement?
    • How does it affect backward compatibility? How does it affect version compatibility?

Saving processing cycles by optimizing foreach

While this post will mostly be around performance improvements at the code level, we want to emphasize that when we write code, we first want it to be readable, correct, secure, and only after that, performant.

Code performance optimization is about modifying an existing code to use fewer resources, keeping the original behavior unchanged.

Improving performance with pre-computed values

PHP_FUNCTION(spl_object_hash) {
// …
return strpprintf(32, “%016zx0000000000000000”, (intptr_t)obj->handle);
}

PHP_FUNCTION(spl_object_id) {
// …
RETURN_LONG((zend_long)obj->handle);
}

wpboost is one experiment to improve WordPress performance by climbing the programming languages abstraction ladder. We experimented with taking some frequently called WordPress PHP functions and shifting them one abstraction level below – from PHP to C. Practically, this is the lowest level of the ladder, but in theory, there is no lowest level; there is also assembly, binary, etc.

To improve its performance, instead of calling array_keys every time, we pre-compute its value (and maintain it whenever the callbacks array gets changed) so that we don’t have to compute it every time within array_filters. With this improvement, we get the number of calls to array_keys down to 790.

Work on performance improvements is rarely a single-person job – it involves a lot of cross-collaboration work. Getting feedback/input and information from others is beneficial to get a deeper insight into some of the proposed improvements.

Here’s a basic school example that sums all digits from 0 to $n:

In any case, working at the PHP C level is beneficial because it will teach you about the PHP internals, and knowing how PHP works internally will make you a better PHP developer.

For the correctness part, WordPress core already has some tests for hooks, and we rely on those, following the testing instructions.

function sum_to_n( $n ) {
$sum = 0;
for ( $i = 0; $i <= $n; $i++ ) {
$sum += $i;
}
return $sum;
}

This is a great example that shows how we should be constantly aware of the potential impact of our code, regardless if it is a performance improvement. We need to find a way to balance the risk and the reward.

This task is still a work in progress – especially in determining other impacts and finding ways around them.

Another good target for optimization is the WordPress hooks system, as shown in the cachegrind output below. This naturally led to the investigation of the class-wp-hook.php file.

In any case, digging into both PHP and WordPress core internals can provide insightful knowledge, providing awareness of how things work – whether at the architecture level, the function level, etc.
Hyrum’s Law, Software Engineering at Google

We need to continue experimenting, be aware of how PHP and WordPress work, and how the code we write and the data structures we choose will affect performance in the long run.

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

With this experiment, one of the functions we tested is wp_slash. We ran a quick benchmark test using microtime() to compare a function written in PHP with its counterpart written in C. Note that even though the percentage is huge, the numbers are small. However, this scales with the number of times the function is called, the input, and the number of users it serves.

$foo = input…
if ( $foo ) {
foreach ( $x as $y ) {
a( $y );
}
} else {
foreach ( $x as $y ) {
b( $y );
}
}