By Thomas Rutter

PHP Speed Optimizations

By Thomas Rutter

Nathan Wong claims that single quotes are faster than double quotes in PHP.

In the recent blog post, he attempts to prove that PHP is able to parse and execute string constants faster if they use single quotes, than if double quotes are used. Benchmark results and source code are provided.

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.

Nathan’s results indicate an approximate 16% speedup when using single quotes in his testing.

This isn’t the first time this optimization technique has surfaced. This PHPLens article by John Lim is a very comprehensive guide to small optimizations in PHP, and has been updated over time to reflect changes in PHP. The article explains that while some optimizations will improve the speed of a very small application, the same optimizations may have a negative effect when scaled to larger applications. John uses the analogy of the sprinter and the marathon runner when describing optimizations that work well for speed and those that work well for scalability.

Interestingly, however, John places the ‘single quotes vs double quotes’ issue into an appendix named ‘Useless Optimizations’ (near the bottom).

‘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.

Thus, while using single quotes instead of double quotes may have a slight performance improvement, its effect is negligible, and he rightly points out that there are many other optimizations that will make a bigger difference to the speed and scalability of your application.

I’d recommend you read the article as it’s a great read and well-written.

When optimizing any code, one should focus only on those areas of the application which take up a significant amount of its running time. Optimizing a section of a code that is only executed once will not be worth your time as much as a section of code that is executed many times. So, if you have a loop whose contents will be executed many times, it would be worth optimizing that which occurs inside the loop.

Another point to make in code optimization is that you will need to compare the cost (in your time, or a programmer’s time) of doing the optimization with the cost of upgrading server hardware. Hardware is comparatively cheap.

In my searching around for actual benchmark data, I found this page of PHP Benchmark Tests. Interestingly, the statistics shown on this page are live – the raw figures shown are computed by the server each time you load the page.

Many of the tests done last only for a few milliseconds in total, so the accuracy of the benchmarks may not be reliable. However, even these help to illustrate which optimizations aren’t very important. The most telling statistics are those for various methods of looping through an array, with the slowest method taking eight times as long as the fastest.

  • Sandy Smith

    I’ve heard the “hardware is cheap” argument several times, and for those outsourcing programming to an outside firm that requires cash payments for every hour worked, it may hold some water.

    However, at no place I’ve ever worked at has such an issue been met regularly with “buy more/better/faster hardware”. Let’s look at it from the perspective of the manager:

    1) You are a salaried employee. You have a fixed cost whether you are utilized or not. You also can be made to work overtime. Optimization is more work for you.
    2) Hardware is not a fix cost and must be budgeted and planned for, over and above your salary. It also requires, on live products, very careful planning to oversee the transition. More work for the manager.

    Is it any wonder that you get pressured to optimize even in cases where an economist would suggest the pareto for the organization is deploying your talents to new business and additional cash to hardware?

  • Matt Anton

    Check out this Benchmarking article, “Benchmarking PHP with no BS”, by John Lim:,id,546,nodeid,114.html

  • awesome post! I always wonder what ways I can optimize PHP without rejiggering my whole app. I would love to hear about little PHP tricks that would provide those sort of 16% performance upgrades.

  • Aaron Wormus

    Trigger, it’s not like by replacing double quotes with single quotes your script will magically get 16% faster. It just means that instead of taking PHP 0.00012 seconds to parse a string it will take 0.0001 seconds (fuzzy math), and in a non-benchmark scenario will probably not even make a measurable difference.

    If you’re looking to speed up a sluggish script, your style of quoting is pretty far down on the list of priorities.

  • TheArgh

    Even if the performance gain is as you say ‘negligible’, it nevertheless is a performance gain that can get interesting when scaled to larger applications. It’s not the main focus, of cours, but it can help nevertheless.

    I have taken a habit of quoting with single quotes, and thus don’t even have to bother about it anymore.

  • Nico Edtinger

    John Lim does not say single quotes are not faster than double quotes. His examples has quotes and concat. But if your string has no special chars or variables, i.e. an array key, single keys are faster.

    Still most people shouldn’t care, because so many other things in their code can be optimized. But there’s no simple how-to for that. A profiler could help. Maybe you could do an article about Zend Studio and Xdebug and stuff to tell your readers something about profiling.


  • George Schlossnagle

    If you’re serious about performance you should be using a compiler cache anyway, in which case this parse overhead (which is so miniscule as to make the cost of implementing it greater than the benefit in likely all cases) is removed.

  • Buddha443556

    I don’t work on many dedicated servers. My clients are small businesses with shared hosting accounts mostly or VPS at best. I don’t find PHP to be my bottleneck but the hard drive. Throwing hardware at the problem or even implementing a software solution like compiler cache is not an option. I have to work with the resources available and make the best of them.

    IMHO optimization should start with design before a single line of code is written. Understanding the underlying architecture and how PHP fits into that architecture is fundamental to a good design.


  • It’s always interesting to read things like this. Thanks for the links to the article!

  • Jaxn

    I always use single quotes when there are no variables. When there are variables within the quoted string then I place those within curly braces. My understanding is that the parser can parse the variables within the string faster if they are in curly braces (and accessing array members is simplier too).

    $foo = ‘just a string’;

    $bar[‘test’] = “This is a string that is not {$foo}”;

    $baz = “Let’s dig deep to find {$bar[‘test’]}”;

    I think it is a good habbit to have, but I wouldn’t go back and change to this style as an optimization technique.

  • (oops, formatted retry – lame that you cannot edit posts here :)

    In addition to the parsing of double quoted strings for possible variable substitutions that typically aren’t there, the poor quality of compiled code from the PHP compiler is a contributing factor.

    Our paper from a few years ago details simple code optimisations that can be made at the PHP compiled code level, the problems with double quoted strings are illustrated nicely.

    The “problem” is that the PHP lexer splits strings around whitespace, and the PHP code generator emits opcodes to concatenate each word back together again.

    In an example from our paper, you can see the compiled code for the following short source sequence.

    < ? $x = 'inefficient'; echo "This is rather $x coden"; ?>
    op 0 2 ZEND_FETCH_W str='x' fetch local
    op 1 2 ZEND_ASSIGN var* 0 str='inefficient' R1 (unused)
    op 2 3 ZEND_INIT_STRING R2
    op 3 3 ZEND_ADD_STRING tvar T2 Vconst

  • Jonathan Snook

    I have to agree with Jaxn… it’s about knowing the performance difference from the get go so that as you’re coding you can use one or the other. It makes no sense to revisit all your code for just quotes. It should rather be a part of your coding practice. You’ll also be able to tell that if you’re using double quotes that you’re obviously including a variable.

  • Very good!

    My site, [URL=]GaulDong Developer Center on PHP programming[/URL] also has several tips and articles on PHP… though not directly related to ‘quotes’ of course ;-)

  • Hi.

    I spend the majority of my life optimising a large text processing system that has to deliver 10gig filtered full text and networked data in real time. In 3+ years I have never worried about whether I used single quotes or doubles.

    If you need to optimise a system the chances are you need order of magnitude increases. You get these from caching, precalculated data, query optimisation, IO tuning, load balancing and lazy evaluation. You can only make these architectural changes if the code is maintainable. If the code is cluttered with fiddly obfuscations in the name of “performance”, then your real performance will suffer. It will suffer because the developers will waste time understanding the code (more likely deleting it) when they should making design improvements.

    Little tips and tricks to save a milisecond here and there may make you feel like a programmer, but you won’t fool a real one for a second.

    yours, Marcus

  • Dangermouse

    Agrred Marcus, good advice!

  • Then again Marcus, the flip side is for those “real” programmers that can save milliseconds AND get the order of magnitude performance increases in a system. By definition you can only optimise a system so far before its not possible any more, especially when it comes to large optimisations. Which means in some cases, all that is left is to squeeze out the milliseconds here and there that you can.

    I think the whole point from anyone reading this blog entry is not so much whether or not saving a few cycles here and there is worth while or not, but to make sure you concentrate FIRST on the places that you can make large improvements, and then work your way down to the smaller performance improvements.

  • Hi.

    Yes this is a diversion from the article’s main thrust, but…

    My point is that even if you are down to the last few percent improvement, you shouldn’t be tweaking (tight loops excepted I agree, but only ever if that’s the bottlneck). Changing quotes around for readability makes economic sense, optimisation falls far short.

    For example, say I change a top level script with half a dozen print statements into single quotes. That will take me about 10 minutes intensive work. Let’s say that 50% of my day is made up of such intensive work, so really it’s 20 minutes of a day. Say I am a junior developer (to put the figures in the best possible light) and I make 30$ an hour. Allowing for sysadmins, tax, insurance, office space, etc I probably cost the company 60$ an hour. Those quote fixes thus cost $20.

    A one off cost? Not a chance. Code has a churn rate, basically how often it is read (and possibly edited). It’s typically 1-6 months, but let’s say three. So that means we have conservatively cost our organisation 7$ per month.

    Assume we manage 20 msec. from this fix (in the heroin sense). Assume we have a 100 page site and the pages take a quarter second each. We have improved the average load by 0.08%. A fully loaded server for such a simple site would cost at most about $200 per month. Thus we saved exactly a one sixth cent per month by spending 7$ per month.

    And that’s trying to make it look good. Add in real payscales, staff turnover and opportunity cost and it then starts to get really silly ;).

    yours, Marcus

  • spybreak

    I consider concatenating echo output with a comma instead of a dot the same type of neglible speed increase.

    I.e. echo ‘Hello’,’ World’; instead of echo ‘Hello’.’ World’;

  • nacho

    Quoting from lastcraft:
    “Little tips and tricks to save a milisecond here and there may make you feel like a programmer, but you won’t fool a real one for a second.”

    I start by saying I didn’t expect such an answer from you … (Are you the real one?)

    I think it’s not only about performance, which it’s proven to be better, but, as someboy else said, it is a matter of understanding how the PHP engine handles your script.

    It’s probably not worth for you to go and modify your script to reflect this fact, that is something only for you to judge, but it is indeed a matter of best practice and learning the underlying framework on which you have to work.

    THAT makes you a better programmer.

  • MickoZ

    Well nacho, if you optimise with how PHP handle your script… then if PHP change the way it handles it on lower-level (but the high-level stay the same), then your optimisation change with PHP version.

    I think the best optimisation will be the one that are done in your own design. We live in a PC World more than in a GameConsole World. I do that analogy, because in GameConsole, you have the chance to work with a stable hardware (at less that is what I believe), and optimise for it. Let’s say a PHPversion is a GameDev and PHP as a whole is PCdev.

    But if you win 95% of time by caching a result and only updating it when needed. Chance are your optimisation will long time last and you will be able to use that kind of optimisation in any language you want.

Get the latest in Front-end, once a week, for free.