Quick & Dirty WordPress Plugin Benchmarking in Debug Bar

At tonight's PDX WordPress Dev meetup (thanks for the pizza Digital Trends) Daniel Bachhuber had some questions about benchmarking a plugin. Benchmarking WordPress itself is easy, but it's harder to isolate a specific plugin, much less a few calls to preg_match_all() within it. The questioned SEO Auto Linker plugin does this on every page load, so any running time adds latency on every page.

Speculation from the meetup is that a PHP regex operating on post content, a blob, and looping through hundreds of links could be pretty slow. Too much caffeine today meant I had to give it a try.

Attempted Benchmarks

My first attempt to benchmark the plugin was the S3 Profiler. All that did is show my dev machine spent a good amount of time running plugins, almost as much for the SEO Auto Linker as for Relevanissi and a bit less than my theme. So ... yeah. That really didn't tell me whether the plugin was doing a lot or if just certain parts of it were slow. Plus, adding a big volume of links to test with was taking a long time to mock up in SQL, while running the plugin multiple times to get a true benchmark wasn't possible with a whole-WP testing tool.

Then I gave wp-cli a try. Daniel is a fan so it seemed like a fast option to get more insight. Unfortunately enabling the Auto Linker for wp-cli was taking far more time than I'd hoped. OK, not really, enabling WP_CLI and testing to resolve mistakes is actually what was taking forever.

A Working Stub (You're using Debug Bar, right?)

After those dead ends I hammered out a brute force benchmarking script:

By running just a stubbed version of the plugin it only tests the questionable parts. And, there's a neutering problem with the above code &emdash; I held back from stubbing a links post type, so it parses content through the regexes but doesn't have any links to replace matches with. Note that it also requires the Debug Bar Console, but that seemed a light prerequisite after all the dead ends.

Results & Conclusions

1. Running time depends most on the length of the content it parses. This indicates preg_match_all() is the most significant impact factor and str_replace() could be a good alternative
2. The number of filtered keywords or links does affect running time. But within a loop they aren't as big an impact as the regex. Limiting these keywords will not have as big an impact
3. Regardless of post size or keyword count, I think the parsing this plugin does should be cached: parse times for a single post on my dev machine ranged from 10ms to 60ms, with about 10 to 50 keywords to parse (as noted, links don't work right in the stub above). If caching isn't built-in to the plugin itself, then a page cache should be required for larger sites