In this new post to his blog Nikita Popov aims to dispel the popular micro-optimization myth of using single quotes over double quotes for a performance boost.

If there is one PHP related thing that I really hate, then it is definitely the Single Quotes Performance Myth. [...] Let's do a random Google search for "PHP single quotes performance": You will get many results telling you that single quotes are faster than double quotes and that string interpolation is much slower than string concatenation. Most of them advise to use single quotes and concatenation to improve the performance of your application. Let's be clear here: This is pointless.

He did some benchmarking of his own to see how the myth would hold up and, as it turns out, it doesn't - "There is none". His proof compares two strings, one normal single-quoted and the other a double-quoted, and the opcodes they generate. They end up exactly the same. Since it's the opcodes that matter, he recommends using something like APC if you're really worried about the performance. He also includes an example using the token_get_all function of PHP to see how fast the strings run through the lexer too (again, almost no difference).

As an added bonus, he also throws in a bit about string concatenation versus string interpolation with some benchmarking scripts and results of their own.

While admitting that micro-optimizations aren't usually worth the time that's taken to worry about them, Gonzalo Ayuso has thrown together some array read benchmarks to show the difference, if any, in where array values are fetched.

Normally our code is coded once and executed thousands of times, and we must keep in mind that CPU time many times means money. We need to balance it (as always). But, WTH. I like micro-optimizations, and here comes another one: Checking the access to arrays with PHP.

He sets up three different options and tests the memory consumption and run time for each:

• Referencing a value from a large array outside a for loop
• Referencing a value from a large array inside a for loop
• Echoing out the value from a large array inside a for loop

Not surprisingly, all three approaches yield just about the same results. It probably has more to do with the size of the large array than how it's accessed. The fetch outside the for loop did come in slightly under the others, but not enough to worry about it.

The XPertDeveloper blog has shared some micro-optimization tips in a new post to their blog today. It's ten things you can do to squeeze that extra little bit out of your application's performance.

This post covers most performance improvement tips related to PHP coding. While working with small website or project it’s ok to ignore these tips, but when you are dealing with large website or project which is going to maintained for long term and which have large number of user base. Developer must have to consider the below tips from the starting of the project.

Their tips include:

• echo is more faster than print
• Always use single quotes for long strings instead of double quotes. Because in double quotes it will search for php variable to evaluate them.
• If you can declare a method as static then let it be
• Try to minimize relative paths for files inclusion.

Keep in mind that these aren't a "silver bullet" for making your application run faster. These sorts of suggestions should only be applied after the major optimizations (caching with something like APC, good application structure) have been put in place. For most of these examples, you'll only really see an improvement if your application makes use of them heavily in a looping structure.

Following on the heels of his previous post, Micro Optimizations that Matter, Brandon Savage has taken on all of the articles out there that tout several common misconceptions about what micro-optimizations make your scripts really run faster in this new post to his blog.

Last week I wrote about some optimizations you can apply to your code that will improve the performance of your site significantly. I also mentioned that regularly an article pops up talking about ways to shave time off your scripts, and I talked about how these articles mostly are bunk. Like this one. The article I linked above is a run-of-the-mill micro optimization list. The difference here is that the author actually makes use of some benchmarks to make their point. So, let's go step by step and discover together why this article takes longer to read than the amount of CPU time it saves.

He covers a few different categories including looping, quotes in strings, echo versus print, pathing, timestamps and using the regular expression functions (like ereg_* and preg_*).

Following some of the "backlash" of Google posting their "performance tips" for PHP developers, Marco Tabini has written up a post with a suggestion of his own - stop teaching developers how to optimize their code and teach them how to code it better from the start.

In principle, I have nothing against micro-optimizations; I just think they're a waste of time - perhaps even more so because they take the focus away from the simple fact that it's a rare performance problem that is cause by the language: the problem, almost inevitably, resides either with the developer, or with an external system.

He explains that it's no so much about dropping them all together as it is starting from the beginning and teaching best practices and good use of standards and proper development practices. That's what we should be promoting, not things that might shave milliseconds off the total execution time.

For those trying to squeeze the absolute most out of their applications, check out these suggestions from Alex Netkachov on a few "micro" kinds of things that could help speed things up in the long run.

Why "micro-"? Because changing logic of your application may give you much better performance boost then applying all these tips. But they still can make your code better. You always need to output something, why do not use "echo" instead of "print"?

He has a list of about thirty things you can do including:

• calling a function is faster then calling a static method
• accessing an initialized variable is faster then accessing an uninitialized variable
• avoid @ (error control operator)
• adding method parameter type hint increases calling time
• cache page output or result of resource-consuming functions
• pre-increment (++$i) is faster then post-increment ($i++)
• an array is a faster alternative to a class with several fields

These hints aren't going to make amazing differences in your code, but they could help get you out of a sticky place where your code just doesn't want to behave.