Profiling WordPress Performance Regression

Pageload regression

I’ve been benchmarking stock WordPress today to get performance numbers for the Cache Translation Object plugin. As I had things set up for it I also tested  the latest major releases – unmodified, clean installations – and found a 40% regression when going from 2.7 to 2.8.

Update: what I measure here is basically the clean startup time, which doesn’t say what the final effect will be on your site with a real theme, plugins and, you know, actual content.

There is often a battle between features, complexity and performance. This unfortunately natural tendency prevalent among programmers should however not result in such a drastic regression.

Update 2: More on this here.

Profiling Performance Regressions

There are a lot of changes in any major release of  a project the size of WordPress so finding the actual culprits in these cases are not always easy — though in this case some of it turned out to be surprisingly simple.

One way to find performance problems is to profile the two versions and compare. Here you can see lists of the cumulatively most expensive functions with 2.7 to the left and 2.8 to the right:

WordPress 2.7 vs 2.8 Profile

WordPress 2.7 vs 2.8 Profile

I’ve marked some interesting parts in the 2.8 profile. What you want to look for are functions that takes proportionally longer to execute and figure out why. KCachegrind (or WinCachegrind) gives many helpful views of call-chains and such things.

In this case the yellow-marked functions are calling the red-marked translation functions which suddenly consumes major resources. Doing nothing, it should be noted as the stock install doesn’t need anything translated.

A victim of Abstraction

So the first, and largest, culprit turns out to be this piece of code:

function &get_translations_for_domain( $domain ) {
	global $l10n;
	$empty = &new Translations;
	if ( isset($l10n[$domain]) )
		return $l10n[$domain];
	else
		return $empty;
}

Pageload regression fix1Not setting up and calling an calling an empty Translations object increases performance again by 17%.

The rest of the regression seems to be mostly caused by changes in sanitize_post(), wp_widgets_init and sanitize_bookmark_field(), which I’ll look at next — tomorrow.

Anyone testing WordPress performance?

Update: With two patches we get back half of the lost performance.

Update 2: More on this here as noted above.

4 Responses to “Profiling WordPress Performance Regression”

  1. Kakel sickan says:

    Much more database intensive the never version av WP maybe.

  2. Inga nya stats för WP +3?

  3. Har tyvärr inte haft tid att köra, men det kommer!

  4. Jey Tilos says:

    This is a nice post, it could be of great help for everyone.

Leave a Reply