There are probably more than a few naive programmers who would read results like this and start to avoid these constructs in their own code for performance reasons. These are the same kinds of people obsessing over a few single or double quotes, who eschew “slow” objects in favor of switch statements that are many times slower than the polymorphic method calls they are trying to avoid.

But, that’s not the end of the story. Larry ran his benchmarks using 2,000,000 iterations. The N really matters here. Sure, iterators are slower than arrays, but you aren’t going to be iterating over two million things. I tend to fetch my database records in lots of 25 or 50. You aren’t going to be making two million invocations of __call. But how many will you make? Under what value of N does the performance of these techniques cease to matter? Is it ten, one hundred, one thousand, or ten thousand? You may be surprised at how few calls your program actually does and how little impact it has on performance.

As Wez and Travis point out in their comments, profiling is the way to find out the potential impact and to discover your true N.

Paul M. Jones has a good example of what I’m talking about. There, call_user_func_array appears to be a bottleneck, but it turns out that its the function being called, htmlspecialchars, not the calling process that consumes the balance of the time. In that case, the function was “only” called 300 times. I find that order of magnitude to be fairly typical. Something to be aware of, perhaps, but not something to obsess over.

I’ve also been impressed with the new upgrade notes for 5.1. Good job there, too.

I’ve read over the whole thing and I like what I see. One thing did jump out at me.

We also discussed whether we should even allow Unicode mode to be turned off as current micro benchmarks show that the Unicode implementations of some of the string functions are up to 300% slower, and whole applications up to 25% slower. Disallowing Unicode mode to be turned off is expected to slow down the adoption of PHP 6 too as many ISPs would be reluctant to install a version that immediately slows down the applications of their users.

I am definitely not familiar with all the issues involved, but wouldn’t this make it hard to write general purpose PHP applications? Programs would have to check whether unicode was on or off? Wouldn’t that checking be slow and complicated, too?

I think its great to discuss ways to improve adoption of PHP 6 so far ahead. It looks like APC will be included. I think thats great news on the adoption front.

I wonder, though, if anyone has gone and asked hosting companies what features they might like to see in PHP 6? I also wonder if it would be helpful to have two upgrade guides: one for programmers and one for hosts. Perhaps even a separate Hosting PHP Applications section as part of the PHP manual. (With things like “How do I find out which PHP script sent out this spam?”)

PHP hosting concerns are not always the same as PHP programmer concerns. Hosts are important to the adoption of PHP and throwing them some love can only be a good thing for the platform as a whole.

The reasoning behind this speedup is that when the PHP compiler encounters a string constant beginning with a double quote, the string itself must be parsed and special characters (such as $, \ and {) have special meanings. By contrast, if a string constant begins with a single quote, only the backslash has a special meaning, and therefore PHP doesn’t have to worry about replacing variables and expressions embedded in the string.

This line of thought is flawed for two reasons.

First, PHP uses flex to tokenize the php source code. Flex is a table driven lexer. It doesn’t necessarily follow that having more characters with special meaning makes flex slower if you don’t actually use those characters.

Second, the original benchmark doesn’t actually measure parsing time. Like all microtime() based benchmarks, the first access of microtime() doesn’t happen until the php file is completely parsed and converted into opcodes. Additionally, it executed each literal inside a 10,000 iteration loop. Thats 1 time to parse it and 10,000 times to execute it.

I put together a different benchmark that does measure parsing time. It consists of two files

 
<?php echo 'very long string'; ?>
 

 
<?php echo "very long string"; ?>
 

The very long string I used was the text of the US constitution: 27,787 bytes. I measured using ab, which includes parsing time. My results:

single quotes: 27.59 ms
double quotes: 27.74 ms

Hardly earth-shattering. Single quotes was consistently faster, but by the same minor margin. This is with a 27k literal string. My guess is that you will never have enough literals in a typical PHP program for any parsing performance differential to matter.

Is there an execution differential? Do both of these constructs generate the same opcodes? I tried to check it out using Vld or parsekit but I can’t get either of these to work in my development environment (OS X). Perhaps someone will reply in a comment with the opcodes for the previous two programs and settle the question.

There doesn’t seem to be much if any difference between single and double quotes for an identical string. A more interesting question would be what happens when the strings aren’t identical. Consider the following three examples:

 
<?php echo "Answer: $answer!"; ?>
 

 
<?php echo 'Answer: ', $answer, '!'; ?>
 

 
<?php echo 'Answer: ' . $answer . '!'; ?>
 

 
Answer: <?php echo $answer; ?>!
 

My gut feeling is that concatenation is slower because of the ability of the output buffer to allocate memory in big chunks rather than little chunks. Other than that, I honestly don’t think it makes a difference, but I would love to compare the opcodes for each of these examples.

The scary thing about microbenchmarks is that they always produce a number, even if that number is meaningless. They measure something, we’re just not sure what. Very often, they only measure the performance of the specific microbenchmark, and nothing more. But it is very easy to convince yourself that your benchmark measures the performance of a specific construct, and erroneously conclude something about the performance of that construct.

Even when you write an excellent benchmark, your results may be only valid on the system you ran it on. If you run your tests on a single-processor laptop system with a small amount of memory, you may not be able to conclude anything about the performance on a server system.

This is why I prefer to benchmark with ab rather than microtime().