php optimization myths
Some optimizations are useful. Others are a waste of time.
Here are some common PHP myths:
a. echo is faster than print
Echo is supposed to be faster because it doesn’t return a value while print does. From my benchmarks with PHP 4.3, the difference is neglible. And under some situations, print is faster than echo (when ob_start is enabled).
b. strip off comments to speed up code
If you use an opcode cache, comments are already ignored. This is a myth from PHP3 days, when each line of PHP was interpreted in run-time.
c. ‘var=’.$var is faster than “var=$var”
This used to be true in PHP 4.2 and earlier. This was fixed in PHP 4.3. Note (22 June 2004): apparently the 4.3 fix reduced the overhead, but not completely. However I find the performance difference to be negligible.
Do References Speed Your Code?
References do not provide any performance benefits for strings, integers and other basic data types. For example, consider the following code:
function TestRef(&$a)
{
$b = $a;
$c = $a;
}
$one = 1;
ProcessArrayRef($one);
And the same code without references:
function TestNoRef($a)
{
$b = $a;
$c = $a;
}
$one = 1;
ProcessArrayNoRef($one);
PHP does not actually create duplicate variables when “pass by value” is used, but uses high
speed reference counting internally. So in TestRef(), $b and $c take longer to set because the references have to be tracked, while in TestNoRef(), $b and $c just point to the original value of $a, and the reference counter is incremented. So TestNoRef() will execute faster than TestRef().
In contrast, functions that accept array and object parameters have a performance advantage when references are used. This is because arrays and objects do not use reference counting, so multiple copies of an array or object are created if “pass by value” is used. So the following code:
function ObjRef(&$o)
{
$a =$o->name;
}
is faster than:
$function ObjRef($o)
{
$a = $o->name;
}
Note: In PHP 5, all objects are passed by reference automatically, without the need of an explicit & in the parameter list. PHP 5 object performance should be significantly faster.
20 Comments so far
Leave a reply
Great Article Justin. This helps bust most of the PHP optimization myths out there on the Internet.
Thanks for sharing your knowledge on this topic.
Well, if I got this right, even if there is no speed gain by doing these “optimizations”, there’s also no loss, right?
I made it a habit to prefer echo before print and always use the concat dot before inserting variables directly into the strings (which only works with double quotes afaik). I also prefer single quotes instead of double ones even if I lose the “enhanced functionality” by doing so.
In my opinion, even if the performance difference is negligible, it’s worth trying because if I’m able to save some ticks a lot of times I get a really mentionable performance gain.
But on the other hand this may simply be the old me who optimized setPixel calls in assembler back in these days to get the most out of the terribly slow CPU
Actually, your points (a) and (c) are not myths, and were recently addressed in Sara Golemon’s blog:
http://blog.libssh2.org/index.php?/archives/28-How-long-is-a-piece-of-string.html
Basically, there are some opcode optimizations when using the concatenation operator versus the implicit concatenation in double qutoes; additionally, echo() is faster than print() when you separate arguments by a comma rather than concatenation operators.
very interesting article matt, thanks for the post.
“In my opinion, even if the performance difference is negligible, it’s worth trying because if I’m able to save some ticks a lot of times I get a really mentionable performance gain”
that’s a good point.
I usually try many different things out before deciding on an optimization that works/is worth it. I have found that many of the opcode generation/caching systems work well (zend,ioncube,etc). Also gzib compressions has helped in some situations quite a bit.
Of course it’s always worth trying whatever seems working and keep these things. I try to make the small optimizations a habit, so I automatically optimize my code while writing it
Sashcha, I added your blog to my list of links (on the right-hand side of my site)
Thanks a lot! So did I
Regarding c. there is another advantage in using single quotes for simple string representations (ASAIK): Since PHP tries to replace every variable occurence in double quoted strings single quotes are just passed by the interpreter as they are defined meaning for
$var = ‘This is a $string.’;
PHP doesn’t replace or even recognize that the string conaints a variable while
$var = “This is a $string.”;
is analysed and the variable is going to be replaced by its current value.
I believe there is some significant difference in performance
Right, I think there is a completely differents parser used for the single quoted strings than for the double quoted ones.
I’m planning to do some special case PHP performance benchmarks for some time now … I’m pretty sure the single versus double quotes test will be included also, if I get to do it some day
Sascha, Please keep us updated. I am interested in hearing more about your benchmarks.
Maybe out of topic maybe not… i think the best issue that this topic may consider is if the speed bump is very negible you have to consider using that optimization time on doing other things.
… on the other, if a code will be executed a many many times a negligible optimization will also have a great effect compounded.
@Dino: That’s exactly my point
Hi Justin,
extremely nice new template, really like it, but it looks like the BlogRoll is gone
thanks!
I will look into getting my blogroll back. I didn’t even notice (mostly because I changed the theme around late lastnight). I appreciate you pointing that out.
no problem
I miss some template changes every time I upgrade my system … and I’m even using the default template 
(a) These optimizations *are* negligible. Period. If you like the look of echo over print, then sure, use it. If you like the look of concatenated strings over interpolated strings, sure, use em. Coding for this minor differences will help your request latency (however slightly), but your own maintainability needs to come first. Which form will you as the site developer have an easier time look at in five years. For me, I quite like non-interpolation and echo.
(b) You’re right about the references. Don’t use them because you think they make your script faster. In many cases they’ll actually slow it down by forcing a copy when it wouldn’t otherwise be needed (Check zend.com, Andi wrote a good article about it about five years ago)
(c) If you’re that concerned about microseconds, get an opcode cache that has an optimizer. APC has a nice one (disclaimer, I wrote a few of its optimization loops), and it’s free as in free so who can complain? When you use an optimizer, the ugliness of string interpolation turns (effectively) into a series of concatenated strings and variables from the executor’s standpoint: “this $is foo $bar baz” ==compile==> ‘this’ . ‘ ‘ . $is . ‘ ‘ . ‘foo’ . ‘ ‘ . $bar . ‘ ‘ . ‘baz’ ==optimize==> ‘this ‘ . $is . ‘ foo ‘ . $bar . ‘ baz’
(d) Stripping comments only speeds the lexing stage by a couple nanoseconds (because it doesn’t have to look for that */ end delimiter. Understand what’s going on in your code is worth those couple nanoseconds. Trust me on this
Besides, you’ll save a lot more by using an opcode cache, and as mentioned above, the opcode cache will quitely throw those comments away (except for doccomments, but those are generally left in shared memory and not re-copied on each request)
Hi,
I always use comments on my Php codes but never put those commented files to my servers. I always strip out all the comments and unnecessary white spaces. This action reduces file size nearly %25 . Do i do unuseful thing by stipping out the comments?
They help in saving some space, but they are pretty useful for editing and or figuring out your source code in the future. It probably does not help you at all, speed wise.