TL;DR: Ray makes it easy to start measuring performance of your code both in WordPress and in standalone PHP solutions.

I don’t know if this is something that’s common within WordPress development, but if you’re working on functionality that deals with a lot of files, a batch of operations, or both, then this is something that may be useful.

⚠️ If you’ve not already set up your environment, please read this post and make sure you have the free version of Ray installed.

Measuring Performance in Ray

First, A Personal Example

Sometime ago, I was working on a PHP script that was running a variety of operations on a large number of image files. This wasn’t a plugin or an extension for anything else; it was simply a script that I was working on to help me backup and archive my videos and images.

The images were in a number of different file formats:

  • HEIC
  • JPEG and JPG
  • PNG

And the videos were in a few different file formats, too.

In short, I like to organize my media by year, month, day, hour, minute, second, and I have a few utilities that I’ve usually used to help me but I thought it’d be easier if I bundled it all into a single script and let it do its thing (this also was giving me a chance to test out PHP fibers but that’s another post).

When I was working on this script, I noticed that certain operations were taking longer than others. This was expected. But I wanted some insights into just how long each operation was taking (and why) to see if I could optimize it and show visual feedback in the terminal.

Specifically, converting HEIC files to JPEG file through the through of ImageMagick all the while maintaining the EXIF data to later use to name the files made for a long operation.

So I started to use Ray to measure just exactly what was going on.

As you can see from each block separated by a timed stamp above, the operation was taking roughly 144 seconds, 4MB of RAM, and 0.44 seconds in between operations.

This is useful information for what I was doing, but the gist of what I was doing versus what I want to share stops here. The point of it is this: Measuring performance in Ray is really easy and in the context of WordPress where we’re going to be working with loops or some type of iterator can be very useful.

This doesn’t matter if you’re processing the results of a query, iterating through a list of data, or dealing with something completely separate.

Measuring Queries and Iterations

To see how the measure function works, let’s set up an example that will do the following:

  1. Query the a set number of records from the postmeta table
  2. Iterate through the list of records in a few different ways

Note we’re not concerned with what the data includes or even to what posts the information is related. We’re just curious about what the speed of which the query takes and the speed of which iterating through the collections takes.

First, note that Ray’s measure method is specifically defined as this:

You can use the measure function to display runtime and memory usage. When measure is called again, the time between this and previous call is also displayed.

Query the Data

So the first thing we’ll do is set up a function that will use the $wpdb class for querying a number records from the postmeta table. Further, it will also include a conditional on whether or not we want to render the results in Ray. This will be useful later in the article.

Depending on the nature of your machine and the number of values you specified to query, your results may be different but you should see something similar to this:

Now let’s test the code with a larger set of data:

Then let’s a run a test with a small set of data:

As you can see, the values linearly increase with the size of the data which, outstanding any type of caching, is what we should expect.

Iterate Through the Data

What if we want to measure the performance of iterating through a loop when working on a plugin? This could be done when using any type of loop (for or foreach or while) or even something like an array_map function.

I don’t want to overstate the point, though. Changing the way in which you measure performance simply based on the type of loop you opt to use is easy enough.

Instead, let’s look at it in action when comparing for and array_map with regard to to sets of data – 100 and 1000. Luckily, we already have the functionality to do this. We just need to measure the performance.

Before doing each of the following, though, I want to make sure that I link to the colors option that Ray provides. Namely, it allows you to stamp a message with a specific color. This makes it easy to know what’s printing the message when several are appearing on the screen at the same time.

Using a for Loop

First, we’ll set the $number equal to 100 and pass it into our custom function, refresh the browser, and then see the results in Ray:

After that, we’ll do the same thing but for 1000 records:

Interesting, right? And we know that for loops are usually linear in nature. What about array_map though, does it do anything differently under the hood? Let’s take a look.

Using array_map

First, we’ll look at 100 records:

And then we’ll do the same for 1000 records:

You can run this a few times and still get roughly the same answers.

But there you have it – an easy way to measure the performance of something within the work you’re doing using built in functions with Ray.

What’s The Conclusion?

Ultimately, the conclusion is that measuring performance in Ray is not only easy, but its enlightening.

Further, I think we know intuitively what things work better than others and we know that caching increases performance, but what if we want to squeeze as much performance out of our code before introducing any other layer along side of it?

Ray makes this much easier. Further, it also allows us to explore bottlenecks that we suspect but may not be able to definitely ascertain without further investigation.

So next time you’re looking at where your code may be slow, don’t forget to use this.

🔖 Remember The Tag

Recall I’m using the develop branch of the repository for each article. After the article, I’ll merge the contents of develop into main and then I’ll tag the version with the date the article was publishing. 

The tag for this article will be 09022022.

We’ll continue to look more into what Ray can do for us within WordPress in the next article.

☕️ Enjoying this guide? Consider Buying Me a Coffee to support these longer form articles!