PHP Team Responds to Google's PHP Tips(groups.google.com)
groups.google.com
PHP Team Responds to Google's PHP Tips
http://groups.google.com/group/make-the-web-faster/browse_thread/thread/ddfbe82dd80408cc
14 comments
I was waiting for that. The history of micro-optimization is replete with myths and legends which sound juuuuuuust plausible enough to be true (or were true a decade ago) and endure to this day.
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."
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."
I don't know if it is really indicative of anything, but I remember micro-optimization being a rather prevalent topic during my PHP days. Perhaps it was just the folks I was reading, I don't know.
The only thing worse than an article about micro-optimization is one that is both out of date and almost entirely backwards.
The only thing worse than an article about micro-optimization is one that is both out of date and almost entirely backwards.
"Don't use the nice readable str + str syntax to concatenate, instead, use StringBuilder"
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.
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.
I (naively) read Google's performance tips as fact and wouldn't have thought twice about it. Lesson learned.
Their tips on how to optimize HTML pages are similarly silly. They suggest removing all end tags, as well as start and end tags that aren't strictly necessary according to the HTML standard, such as the 'html', 'head' and 'body' tags.
Saving a byte here and there for the sake of transfer-speed, without a thought for rendering speed or maintainability, is apparently ideal.
Saving a byte here and there for the sake of transfer-speed, without a thought for rendering speed or maintainability, is apparently ideal.
Re: dropping HTML end-tags that can be inferred
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.
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.
Wouldn't it be kind of weird if Google's optimization tips were primarily meant for the relatively scarce few websites that operate on the scale at which their tips are even meaningful, whilst not even dropping a single hint to that fact, and in the process confusing everybody else?
It's probably just a factor in parsing, which is plenty fast anyway; it would have no effect on rendering.
Even if all the tips were valid, the performance gain is tiny in comparison to simply installing an opcode cache (APC/Zend/etc).
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.
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.
In very high volumes, tiny performance gains change user behavior.
Let's be honest, though. Most people accepting these tips without second thought probably aren't catering to high volumes of people.
Noticeable performance gains change user behavior at any volume. The only difference volume makes is the cost-benefit, ie. it's a no-brainer for google to spend $100,000 for a 5% gain in their home page performance which is not true for the vast majority of sites.
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.
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.
In very high volumes, tiny performance gains might help each server handle a few more requests - but in that case, you're better off just adding another server rather than changing all the prints to echos or whatever ;)
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.
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.
"When simple strings with no variables in them are used, the performance is clearly better with double-quoted strings due to implementation details in the engine."
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?
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?
If I was going to guess, I'd say that double quoted strings are passed to a different "engine" than the single quotes, and perhaps over time the double quote engine has received better optimization.
Yeah, thats what I also figured but, really, how much can you optimize a constant string literal (which I'm given to understand the single-quote thing is)?
Must be some kind of caching optimization and not really something that saves CPU cycles
Must be some kind of caching optimization and not really something that saves CPU cycles
Single quotes aren't a constant string literal, because they have to parse \'.
Guesstimate: if someone cares about performance, they should have already installed an opcode cache, which probably wouldn't have to re-parse constant strings.
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.
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've found that the only way to get accurate information about performance is to test it myself or use a source that actually gives data. I tested this myself a while ago and found no detectable difference between single and double quotes. (And if I hadn't done this, I'd know not to trust this post:) )
The wording wasn't clear, but the example code given was: Using an interpolated double-quoted string is faster than using 2 or more concatenated single-quoted strings.
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.
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.
That does sound counter intuitive. But even if performance differences are negligible, I still find it much more efficient, or at least ergonomically comfortable, to use single quotes with only one finger/keystroke, no need for shift. Same reason I dislike PHP's arrow -> for methods/properties, that's three keys right there, vs. just a dot in other languages.
That quiet sound you sometimes hear is emacs, calling you.
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.
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.
It should probably be noted, however, that the original article's suggestion to "avoid doing SQL queries within a loop" is still a good one. Granted, this isn't PHP-specific, so perhaps this wasn't the right place for it. Furthermore, on small traffic websites (which, as other commenters mentioned, are probably the target of an article like this) likely wouldn't see a significant speed up, given the low query volume. Nevertheless, minimizing trips to the database is a good idea.
APC opcode caching absolutely turbo-charges PHP. Quadruple performance.
I'll take your word on it. Since I use an inexpensive (shared) hosting service, how would I go about checking to see if they employ APC opcode (or any other such as listed at http://en.wikipedia.org/wiki/PHP_accelerator ) ?
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)?
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)?
No, you're probably not going to ever see this in a shared hosting environment. That might change, though: the next version of PHP is going to have APC added (but not enabled) by default.
As far as I'm aware how it works at the moment means that everyone on a shared server would be working from the same cache hence you have security issue.
With stat off, of course.
related and helpful - http://www.phpbench.com/
Some of those benchmark results were surprising.
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?
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?
Wow! What a stinging rebuke. ... and well-deserved, it seems.
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.
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.
Very nice response by the PHP team IMO. I fell out of love with PHP a looong time ago but harbor them no ill-will. Seeing how silly some (most?) of the suggestions Google gave was very disappointing.
Truly disheartening. I've also trusted Google without thinking twice...lesson learned. Myself and others I'm sure are now going to take Google's "tips" with a grain of salt.
Wow, that's funny. When I read it, I was thinking, "Can this (or that) really make a significant difference.?". Then I thought, "Well, it must since it's on Google's tips page.". Bzzzzzzzt. Wrong.
I feel sorry for all the people who instantly started hacking (as in machete) up their entire app based on this advice.
I feel sorry for all the people who instantly started hacking (as in machete) up their entire app based on this advice.
PHPwn.
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