php passing pointer parameters performance

A little adds up to a lot, and in the world of code, a tiny change in code performance can have a big impact on application performance overall.

So, pointers aren’t a “thing” in PHP. This article is about the use of PHP References, and I used the word ‘pointer’ in the title because it is alliterative. So there :)

how to test performance of small blocks

So there are plenty of theories on how to test code performance, but this simple script below can trivially compare 2 blocks of code. Both blocks must be executed an equal number of times, with as little risk of other system interference as possible. This means you don’t run one block of code 1000 times and then run another block 1000 times to compare them – this risks external influences affecting one of the execution cycles much more heavily than the other, tainting your results. So you run one, then the other, then repeat, capturing times for each execution as it happens.

So I’ll be using this code to show how performance differs when writing your code slightly different ways. Sometimes the difference is very small, and you are welcome to reproduce these tests and come to your own conclusions, this blog contains only my professional opinions.

Sometimes the code set up cost should also be taken into account – if the code in question is called a small number of times in a single execution of your code then the set up cost of a block of code will have a bigger impact on performance. I will include the code I used to perform these tests below so you can see where I have included set up cost in the calculation.

passing variables by reference

Passing variables by reference is when you use the & prefixed to an argument in a function, so any changes made to that variable in the function will also affect the variable that was passed into the function.
These parameters are called references, passing ‘By Reference’ being the opposite of passing ‘By Value’ which is when you pass a variable without the ‘&’ prefix.


results in the following execution times:

So not a lot of difference there, but you can already see the funcB() function is very slightly faster.

But… Consider what happens you are working with larger data blobs. All of a sudden you are calling a function changeData1() with large amounts of data that PHP has to allocate memory for, copy it, alter it, then remove the original (and later garbage-collect it). This can happen when modifying the contents of a file, for example:


It was ~45% faster to use a reference here.
So when working with large strings, it is a lot more performant to alter the existing string, than to copy the passed string and return it.

On a large array:


So we took ~32% off the processing time here by passing our variable by reference.

we can also use the reference operator & in a regular foreach loop.

Here’s an example:

And our survey says:

Sooooo…. We nearly improve the performance of this code by ~54%, just by using a reference instead of modifying the array values by key.

using a reference to reduce calls to nested variables

Why write this code:

when you can do this instead:

Much better :)

use unset when you want to redefine the reference

When working with references, it can be pretty easy to accidentally modify data you didn’t intend to, consider this:

This code sets $bar to null. The reference $foo is still pointed at $bar.
If you want to stop $foo pointing at $bar you have to point it at something else,
eg. $foo =& $somethingElse
or you need to call unset($foo).

Common methods in PHP already use references for performance reasons, such as:

for sorting the elements in the given array
function sort (array &$array, $sort_flags = null) {} (and other array sorting functions)

for randomly re-ordering elements in the given array
function shuffle (array &$array) {}

for iterating over the given array, modifying values as it loops over items in the given array
function array_walk (array &$array, $funcname, $userdata = null) {}

for getting the current element in the given array
function current (array &$array) {}

for adding a variable to the end of the given array
function array_push (array &$array, $var, $_ = null) {}

So all of these methods modify the given array in-situ, rather than returning a modified copy of it.
If you think about it, this makes a lot of sense, because if you want to retain the original array before you modify it, then it’s just one line of code to copy the array; but if these functions always returned a copy of the given array, you would have to write your own function to modify the original array in-situ if you wanted the performance gain.

Other core functions in PHP use references for passing data back to the calling code, for example:

The signature for this function is:

This can be very handy when you want to change an existing function to return more than one variable, but don’t want to change all the existing usages of the function in your code. Just tack on an optional reference parameter to the function signature and use that to return your extra data. And maybe design your system better next time :D

you don’t need to use references to objects

When passing objects around, copies of them are NOT created by default. So you don’t need to use references in this case, the original object will still be modified by your function. See example:

If you use a reference on the parameter here it doesn’t give you any warning, because the parameter may accept primitive types as well as objects, which would otherwise be passed ByVal instead of ByRef.

ye olden days of references in php

For those who are interested, in PHP’s history, parameters to be passed by reference use to have to be specified in the calling code, instead of the function signature, like so:

But if you try to do this today, you get a Fatal error….

Further Reading

PHP Manual: References
Stephen Morley: PHP references tutorial

code smell – objects vs arrays

“Code Smell” is a term that I have heard used in the past, and regularly use myself to describe code that may work fine, but just doesn’t seem as good or clean as it could be. Maybe there’s some repeated code, or unnecessary over-use of strings. Basically the code smells bad.

Use objects instead of associative arrays for working with collections of values.

Here’s why…

In Javascript, it is now commonplace to see a single object passed to a method as a collection of parameters.
This is for code flexibility, so you can call the method with as many or as few values in the object as you like, and you can build the list of values to be passed to a method over a larger area of code. It also means you can simply forward the parameters object to another method, perhaps modifying some of the parameters between calls.

So the community has accepted this is convenient way to pass parameters around – I’m not saying this should be done everywhere, in fact this should only be done when it smells right to do so… Currently one commonly used option is to use associative arrays to accomplish this. Here are some unexpected drawbacks:

  • $arr['foo'] can’t be described using /** @var */ (or PHPStorm doesn’t support it).
  • $arr['SomeVariebleName'] won’t show the typo when you meant $arr['SomeVariableName']
  • $arr['bar'] might be not set, and you’d have to use isset() or similar function to determine if it has been set.
  • $arr['foo'] is slower than $arr->foo. Not by a lot, but it is.
  • finding all the places in your code that $arr['foo'] is used when your array keeps getting passed around, is hard work.
  • you have no dedicated place to put functions for interacting with this array of parameters.

To fix some of these issues you might convert your array to an object using a cast:

However, you still have no dedicated space to describe the object – $arr->foo still has no built-in PHPDoc, no default value, and if you are likely to use the same object in multiple classes, you end up reproducing blocks of code, which also smells bad.

Here are some solutions…

So here we’ve completely replaced using the array with using a custom object, in the same way that we would use a STRUCT in C. No methods, just a class that contains a bunch of properties. Using this object makes reading the code easier, tracing code easier, and refactoring code easier. And all it takes is a tiny little class that can be re-used elsewhere in your project.

What about when we have an array and we need to convert it?

Good question. We can add a constructor method to our class to make this easier:

This technique demonstrates replacing an associative array with an object, to improve performance, maintainability, readability and to reduce code duplication. That is all.

Some folks might say

you should always have setters and getters to access object properties

but these people are wrong. KISS!!

There is a time and a place for getters and setters (or accessors and mutators if you’re in academia) and this is not it. You can add them if you like, but IMHO you’re just adding unnecessary code. Remember that you’ve already improved your code with this simple step above, there’s no need to go overboard.

This is a simple class, and if you want to add complex functionality like input validation (which is one of the main reasons for using setters), then you’re better off using a validation class that validates the input data, and a hydrator class that populates the object, which is beyond the scope of this blog entry.

It is possible to reduce the code a little using PHPDoc instead of explicit properties – I advise against this as it reduces code clarity, but I’ll describe what I mean here anyway, so I can show you a slightly more unusual PHPDoc use-case:

So this happens in PHPStorm:

PHPStorm recognises @property values

So the only practical difference between this and the previous code above, is that we can’t use default values for the properties unless we add them as real properties of the class. Also, parsing annotations in this class won’t work as effectively as it would for the previous example, because we are describing properties within the class docblock, instead of using dedicated docblocks for each property.

(A docblock is a /** ... */ , not to be confused with a multi-line comment /* ... */.)

All the examples above allow you to add any property to the class, so by default it doesn’t prevent you from setting a property to the object that it doesn’t expect to have.
PHPStorm will warn you that you’re using an unexpected field, but it will still let you set the property:

PHPStorm Field not found
PHPStorm field declared dynamically

So here’s one way to prevent custom dynamic fields being set in your object, that still retains most of the above functionality:

We’re using the __set() magic method to throw an exception if we try to set a value to a property that doesn’t exist. Simple.

line-level code deduplication

When you’re learning about object-oriented code, people use “code deduplication” as one of the reasons for modularising your code, to increase code re-use, and the cut the number of times the same blocks of code are present inside any given system.

The following phrases are some of those that all developers should be thinking:

  • “If I want to re-use this block of code, maybe I should put it in a method…”
  • “If I want to re-use these methods, maybe I should put them in a separate class…”
  • “If I want to re-use this set of classes, maybe I should put them into a bundle…”

These thoughts all focus on code re-use for the purposes of maintainability, and de-duplication of effort. They focus on code-deduplication at Method, Class, and Module levels, respectively.

What these statements have missed, is that there is one more important reason for deduplication, that of code performance.

Code performance is overlooked often in so much of the code that I see, that it is often the number one reason that I end up spending time refactoring.

Consider the following code. It suffers from code duplication at the line-level that reduces readability, performance, and maintainability.

Repeated calls in this statement:

  • $filters->getDateFilter() – occurs 9 times
  • $searchQueryBuilder->applyFilter() – occurs 4 times
  • $filters->getDateFilter()->getFrom() – occurs 4 times
  • $filters->getDateFilter()->getTo() – occurs 4 times

There are several methods in the above code that are repeatedly called, even though we know that the result will always be the same.
(If we know that the result may change between calls, then this should be illustrated in a comment, but only badly written code would prefix a mutator method with ‘get’)

In the code above, these repeated calls have each been replaced with a single method call, using a local variable to store the result when appropriate, so it can be referenced without repeating the call. Code that is not necessary to be inside of the switch statement has been relocated after the switch statement.
This code could be shrunk further with the use of stringified method names, but in this instance is unnecessary, makes code tracing and maintenance harder, and reduces code readability and possibly also affects performance to a small extent.

Here is an example of how you could shrink the code further:

This shrunk code does have the advantage that it is the most flexible, in that even the Exception message is dynamic, so adding a new type now only involves adding one line of code.
From the perspective of code tracing and maintainability, you could add a PHPDoc @var tag to tell any watching IDE that the resultant class could be an instance of any one of the four listed classes from above:

But this just starts to get silly, and we are again repeating the class names from the list for the purposes of IDE integration and code documentation.

Some developers would prefer to use an inline formatted layout for the switch statement as below:

Recently I have been avoiding this code pattern, as it is against the PSR-2 Code Style Guide layed out by PHP-FIG – This is one of the standards I follow, and my IDE is configured to auto-format code which prevents me using this pattern. This is one of the (very few) things I dislike about the PSR-2 guide.

primary path code style

This is a quick breakdown of a simple technique I use when laying out code within methods.

Basically it refers back to a common rule used when drawing logic flow diagrams, that the primary path in a logic flow diagram will follow the central vertical line from top to bottom.

This indicates that any non-standard route will follow a logic path that deviates from the central vertical line, and perhaps rejoins it further on.

Working on this idea, code methods and logic flow diagrams should be written in a similar fashion – if there are fewer lines in a logic flow diagram, then it is a simpler diagram. A line in a flow diagram basically translates to a code block in code, so the fewer nested blocks there are, the fewer lines in the diagram there would be.

If two flows in a diagram share roughly equal likelihood, then this rule has less significance, as mutually exclusive nested blocks must exist within the code to represent this. Consider whether the method could be split out into separate methods if this is the case.

As personal preference, I try not to nest code more than 3 levels deeper than the initial depth of the method. (This will start at 2 levels deep for a class method, one deep for a function.)

Here’s an example of some code:

This code demonstrates a problem I see regularly, and it follows a pattern that breaks the primary path code style. In this example the primary path only executes funcA() and funcB() and then deviates into two parallel paths, instead of suggesting which path is most likely. Normally having this separation would be fine, because it is entirely possible that the two paths (the if/else blocks) are equally likely – but in this case the else case only exists to throw an Exception if the if statement is not met.

This breaks our rule, as an exception should only be thrown in cases of exceptional circumstances, hence the name. The only caveat to this is if the doSomething() method serves the primary purpose of throwing an exception in the first place, which in this case it does not.

This code can be simplified following the primary path code style as follows:

Here we can see the primary path now says that funcC() and funcD() are part of the primary path, and has a greater likelihood if being executed than throwing the Exception does.
You should also note that this version of the code takes up less space on disk, as there is reduced indenting, and the } else { line is no longer required.

To a further extreme, I have seen code that looks like this, but with very many more lines:

You can see how this pattern-ignoring coding has lead to much unnecessary indenting, and generally more difficult to read code. Here it is simplified:

This code has **exactly** the same functionality, but now follows the pattern, and you can easily see the code that follows the primary path, and you’ve saved some disk space too.

If you think about how if statements are actually processed and executed by the CPU, else statements don’t really exist in assembly in the same way they do in abstracted languages like PHP – in assembly, an if statement is akin to a JMP to jump to a different instruction block depending on the outcome of a comparison statement, (==0 JZ, >=n JGE, <n JL, etc.)[1]. If the comparison doesn’t match, the jump doesn’t happen, and the execution point moves to the next instruction. It is therefore more processor efficient (albeit slightly) to have fewer ‘if’ statements that match the statement, as this means fewer jumps, and fewer instruction blocks.
Whether this performance gain translates upwards into highly abstract languages such as PHP is not likely to be noticed, or even detectable, but it’s always good to try to consider the instructions you are sending to the CPU once in a while, and ask yourself, is there a more logical way to walk through this code?

the importance of being logged

This is a helpful reminder to everyone (me included), to always add logging to the system you’re working on.

If a code block is exiting abnormally, or results are not as expected, this obviously needs to be handled in the code, but is often the result of an external problem, and so should be recorded to a log file. In most circumstances this only involves adding one line of code. All logging facilities use different levels of logging output to differentiate the severity of the message, and to disable the more verbose levels in production systems, to save processing, disk space and I/O bandwidth.

Throwing a generic Access Denied Exception can be backed up with a more useful logging message, for analysis:

Exceptions should only be thrown under exceptional circumstances, hence  the name. This situation is worthy of being logged.
Instead of this:

We should be doing this:

Logging is a very useful development aid too, but consider not removing all your debugging output when your code is all working and polished.

I’ve used logging numerous times in the past to diagnose when a system is experiencing Fatal errors, beit from Syntax to SegFaults – using logging on a line-by-line basis, outputting simply the __CLASS__ name and __LINE__ number, and flooding files with these statements is sometimes the only way to track down the fault.

So if the message you’re logging contains no static parts, remember that it will be harder to find in the code later on! So include something like the current class name, or use the special built-in magic constants that PHP has to offer: