

PHP Team Responds to Google's PHP Tips - hailpixel
http://groups.google.com/group/make-the-web-faster/browse_thread/thread/ddfbe82dd80408cc

======
CalmQuiet
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
That was the most important comment I had seen. I'm kind of surprised Gwynne's
did not include similar links.

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

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

~~~
tjogin
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
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.

~~~
tjogin
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?

------
nir
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
In very high volumes, tiny performance gains change user behavior.

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

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

~~~
WilliamLP
Single quotes aren't a constant string literal, because they have to parse \'.

~~~
DougBTX
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.

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

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

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

~~~
encoderer
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.

------
mindaugas
related and helpful - <http://www.phpbench.com/>

~~~
Shakescode
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?

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

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

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

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

------
erlanger
PHPwn.

------
pbhjpbhj
pwned

~~~
pbhjpbhj
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.

