6 ms·
PHP Team Responds to Google's PHP Tips
- patio11 17y agoI 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."
- tdavis 17y agoI 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.
- ReturnTheGift 17y ago"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.
- pbhjpbhj 17y agopwned
- pbhjpbhj 17y agooo, I used to have karma! Seriously this was my first reaction, as one of the first posters, Google were pwned. Guess I have to open a new account now.
- randallsquared 17y ago"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?
- chaosmachine 17y agoIf 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.
- statictype 17y agoYeah, 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
- WilliamLP 17y agoSingle quotes aren't a constant string literal, because they have to parse \'.
- DougBTX 17y agoGuesstimate: 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.
- WilliamLP 17y agoI'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:) )
- dimarco 17y agoI (naively) read Google's performance tips as fact and wouldn't have thought twice about it. Lesson learned.
- tjogin 17y agoTheir 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.
- gojomo 17y agoRe: 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.
- DougBTX 17y agoIt's probably just a factor in parsing, which is plenty fast anyway; it would have no effect on rendering.
- tjogin 17y agoWouldn'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?
- erlanger 17y agoPHPwn.
- CalmQuiet 17y agoDespite google dropping ball on this one, some good may come from it having spurred Gwynne Raskind's reply: Anyone out there writing PHP might find real optimization value from Alex Songe comments, concluding with (following Gwynne's article): Good resources (written by the guys who actually work on the php engine): http://ilia.ws/files/phptek2007_performance.pdf http://ilia.ws/files/phptek2007_performance.pdf (13 MB) http://ilia.ws/files/phpquebec_2009.pdf http://ilia.ws/files/phpquebec_2009.pdf ( 1.1 MB ) edit: added file size
- invisible 17y agoThat was the most important comment I had seen. I'm kind of surprised Gwynne's did not include similar links.
- dxjones 17y agoWow! 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.
- mindaugas 17y agorelated and helpful - http://www.phpbench.com/ http://www.phpbench.com/
- Shakescode 17y agoSome 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?
- ckinnan 17y agoAPC opcode caching absolutely turbo-charges PHP. Quadruple performance.
- CalmQuiet 17y agoI'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 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)?
- encoderer 17y agoNo, 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.
- robryan 17y agoAs 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.
- erlanger 17y agoWith stat off, of course.
- nir 17y agoEven 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.
- quizbiz 17y agoIn very high volumes, tiny performance gains change user behavior.
- norova 17y agoLet's be honest, though. Most people accepting these tips without second thought probably aren't catering to high volumes of people.
- dasil003 17y agoNoticeable 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.
- nir 17y agoIn 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.
- MikeRB23 17y agoTruly 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.
- Tagith 17y agoIt 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.
- flooha 17y agoWow, 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.
- bdmac97 17y agoVery 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.