PHP Team Responds to Google's PHP Tips

http://groups.google.com/group/make-the-web-faster/browse_thread/thread/ddfbe82dd80408cc

by hailpixel • 17 years ago

153 39 17 years ago

groups.google.com

patio11• 17 years ago

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

tdavis• 17 years ago

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.

ReturnTheGift• 17 years 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.

pbhjpbhj2• 17 years ago

pwned

pbhjpbhj2• 17 years ago

oo, 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• 17 years 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• 17 years ago

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.

statictype• 17 years ago

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

WilliamLP2• 17 years ago

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:) )

tremendo• 17 years ago

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.

mechanical_fish• 17 years ago

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.

encoderer2• 17 years ago

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.

dimarco• 17 years ago

I (naively) read Google's performance tips as fact and wouldn't have thought twice about it. Lesson learned.

tjogin2• 17 years ago

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.

gojomo• 17 years ago

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.

erlanger2• 17 years ago

PHPwn.

CalmQuiet2• 17 years ago

Despite 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   (13 MB)

http://ilia.ws/files/phpquebec_2009.pdf ( 1.1 MB )

edit: added file size

invisible• 17 years ago

That was the most important comment I had seen. I'm kind of surprised Gwynne's did not include similar links.

dxjones• 17 years ago

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.

mindaugas• 17 years ago

related and helpful - http://www.phpbench.com/

Shakescode• 17 years ago

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?

ckinnan• 17 years ago

APC opcode caching absolutely turbo-charges PHP. Quadruple performance.

CalmQuiet2• 17 years ago

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)?

encoderer2• 17 years ago

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.

robryan• 17 years ago

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.

erlanger2• 17 years ago

With stat off, of course.

nir2• 17 years ago

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.

quizbiz• 17 years ago

In very high volumes, tiny performance gains change user behavior.

norova• 17 years ago

Let's be honest, though. Most people accepting these tips without second thought probably aren't catering to high volumes of people.

dasil003• 17 years ago

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.

nir2• 17 years ago

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.

MikeRB23• 17 years ago

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.

Tagith• 17 years ago

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.

flooha• 17 years ago

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.

bdmac97• 17 years ago

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.

PHP Team Responds to Google's PHP Tips

Related Stories