Hardcoding and WordPress Performance

Question

On the WordPress Optimization/Performance page it suggests hardcoding static variables rather than referencing them through WordPress functions. I think I get the rationale behind that.

But what about doing something like the following:

function foobar() {

    global $post;

    $post_ID = $post->ID;

    $site_url = site_url();

    // Use $post_ID and $site_url multiple times throughout the function

}

Is this better performance than explicitly calling $post->ID and site_url() each time you'd want to reference them? Or does it not make a difference?

Answer 1

This is a PHP question not related at all to WP, but since it was upvoted....

TL;Dr version - Compilres do this kind of micro optimizations much better then you, no point in even trying.

lets look at what compilers will do with your question code

// is this less efficient
$meta = get_post_meta($post->ID,'meta');
$permalink = get_permalink($post->ID);

//then this?

$post_ID = $post->ID; 
$meta = get_post_meta($post_ID,'meta');
$permalink = get_permalink($post_ID);

On the first section the compiler can see that you use $post->ID twice without doing any modification to the $post object and it will calculated the value only once and use it in both calls.

The second section basically does what the compiler would have done by itself but since it has more text to it you parsing is slower and therefor the total execution time is longer

But what about

 foo1(site_url());
 foo2();
 foo3(site_url());

 // vs

 $site_url = site_url();
 foo1($site_url);
 foo2();
 foo3($site_url);

Here the compiler can't assume that the result of site_url() will be the same in every usage so no optimization can be done and the second version will probably be faster.

BUT..... what if down the road you decide that the call to foo3 is not needed and you remove that line? we back again at a situation where you code does exactly what the compiler will do by itself, but make the parsing slower

And can you really be sure that foo2() will not be changed down the road to do something that modifies the result of site_url()? with the optimized code it will create a bug.

This things are premature/early optimizations and you should avoid the urge of doing them as they usually have very little impact on the performance of the site.

The recommendations in the linked codex are BS. I will not go into how the use of options in wordpress is optimized by the core itself, therefor what that article claims is that

$a = 5;

is faster than

$a = foo();

function foo() {
  return 5;
}

Which is true but the difference usually doesn't worth losing forever the ability to manipulate those values by plugins, and the ability to manage those value from the admin.

Answer 2

The page you linked to is suggesting hardcoding values that may otherwise result in a database query. Something like the site url is an option that is autoloaded and cached, additional calls do not result in additional database queries. I'll say that both of the examples you've given will make a difference close enough to zero that it's not even worth worrying about.

Answer 3

There is trade off between cpu & memory optimization. If you store values in variables rather than calling function and getting values at run time then it will certainly optimize cpu performance but it will consume more system memory.

Answer 4

As Vinod Dalvi already explained, storing variables instead of calculating them over and over again will save CPU but consume more system memory. You'll have to find a good combination of CPU and memory usage. This combination may differ on different servers, so it's hard to give a good idea of how much you should store and how much you should calculate.

When you really want to make your codes as fast as possible, you should analyse your scripts on efficiency. This can be done as shown in this StackOverflow question. It's the best if you analyse your scripts, change some variables, analyse it again, et cetera. This should be done on different servers, to get a good idea of how far you should go in storing and calculating.