PHP Team Responds to Google's PHP Tips
groups.google.com
groups.google.com
Good resources (written by the guys who actually work on the php engine):
http://ilia.ws/files/phptek2007_performance.pdf (13 MB)
http://ilia.ws/files/phpquebec_2009.pdf ( 1.1 MB )
edit: added file size
I'm currently involved in a project at work which requires translating a (Java) coding standards document. I have filed probably two dozen bugs against the document that sound like "The rationale for standard 2.4.3 is translated correctly from the Japanese but contrary to technical fact." They include my personal favorite Java performance tip "Don't use the nice readable str + str syntax to concatenate, instead, use StringBuilder."
The only thing worse than an article about micro-optimization is one that is both out of date and almost entirely backwards.
Depending on who the audience is for your coding standards, this may not be a bad standard to have. In certain scenarios (e.g. building a very large String in a loop), appending with a StringBuilder can be vastly more efficient than "str+=" concatenation. Without the standard, the audience needs to know when it's not appropriate to use "str+=" concatentation.
Saving a byte here and there for the sake of transfer-speed, without a thought for rendering speed or maintainability, is apparently ideal.
At a large enough scale, it might be worth it, especially if the stripping were automated as part of deployment, so origin-side authors can use whatever's most readable.
Do you know for sure that rendering engines are slower when having to infer end-tags? I would think the most common case is when you elide a end-tag by just ending a containing element, instead. I can't imagine that being a big rendering delay.
And even after installing the opcode cache, performance for many web apps doesn't improve much as the bottleneck is often in the DB. Caching DB results where possible (pretty simple to implement with your own code or an external library) often results in far greater performance gain than any type of code optimization. If you can actually cache the resulting HTML (all or parts), even better.
But we're still talking about improvements of at least 1%. Some of this PHP stuff Google was absolute nonsense--not just because it was technically wrong, which it was--but because string quoting method is never going to make even a single millisecond of difference in any real world PHP app. Even in contrived situations where it would, you could probably make an optimization that would have 3 orders of magnitude more difference by caching or using a C extension. This is the type of nonsense that 16 year old bedroom hackers with no experience or formal education come up with for their first blog post. Google out to be ashamed.
It is important to have scaling in mind when coding, but that had more to with eliminating 50 SQL queries per request situations - the code itself, certainly in a high level language like PHP, should be written for easy maintenance rather than performance IMHO.
Is there any way this could be true except that they went out of their way to slow down single-quoted strings? How could it possibly be slower to do fewer steps?
Must be some kind of caching optimization and not really something that saves CPU cycles
But then thinking: you'd expect constant double quoted strings to also get this treatment, so single quoting still gets you nothing.
All the above is void without benchmarks.
I can type the => character in one keystroke using emacs, though my key combo does technically contain two keys. I could reduce it to one if I really wanted to.
(And I might, because I just found an entire redundant key on my Kinesis keyboard that I never use -- the one right below the X key. Thank you for prompting me to look for such a key. To an emacs user, finding an entire spare key under a finger is like striking gold.)
Similarly, I found that Ruby doesn't use ; as often as :, so I swapped the two when in Ruby mode.
That said, I don't like the arrow operator either, but it has nothing to do with typing. It has to do with the other side of ergonomics: Visual clutter when reading. In a similar vein, the array() operator is my pet peeve: tons of redundant characters, even if you invent a macro for typing it.
That doesn't no longer holds true when comparing a non-interpolated double-quoted string and the identical single-quoted string
Tho as others have said, if you're interested enough in optimization to worry about what type of quote you're using, you should just use opcode caching (APC) which will optimizing string parsing along with everything else.
PHP info page doesn't show anything but "Zend optimizer" (which is not a caching optimizer).
Are APC or any such accelerators/cache-optimizers commonly used by hosts (silently, without showing up in PHP info)?
And some of the interpretive comments were more so: saying "little difference" when there was a 2:1 difference.
The fellow does say he continues the work and is open to feedback, so perhaps some of you with more sophistication about benchmarking can check it out?
Considering Google's influence and reputation, it's really important the PHP Team took the time and effort to respond to the "tips" and set the record straight.
I feel sorry for all the people who instantly started hacking (as in machete) up their entire app based on this advice.
Seriously this was my first reaction, as one of the first posters, Google were pwned.
Guess I have to open a new account now.