PHP Team Responds to Google's PHP Tips • Hacker News Board

Re: PHP Team Responds to Google's PHP Tips

#21

Post by norova » Sat, Jun 27, 2009, 6:36 PM UTC

quizbiz wrote: post #19

nir wrote: post #15

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 an…

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.

Re: PHP Team Responds to Google's PHP Tips

#22

Post by MikeRB23 » Sat, Jun 27, 2009, 6:40 PM UTC

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.

Re: PHP Team Responds to Google's PHP Tips

#23

Post by gojomo » Sat, Jun 27, 2009, 7:06 PM UTC

tjogin wrote: post #18

dimarco wrote: post #7

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.

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.

Re: PHP Team Responds to Google's PHP Tips

#24

Post by mechanical_fish » Sat, Jun 27, 2009, 7:15 PM UTC

tremendo wrote: post #20

randallsquared wrote: post #5

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

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.

Re: PHP Team Responds to Google's PHP Tips

#25

Post by DougBTX » Sat, Jun 27, 2009, 7:47 PM UTC

gojomo wrote: post #23

tjogin wrote: post #18

Earlier quoted context omitted.

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.

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…

It's probably just a factor in parsing, which is plenty fast anyway; it would have no effect on rendering.

Re: PHP Team Responds to Google's PHP Tips

#26

Post by CalmQuiet » Sat, Jun 27, 2009, 7:51 PM UTC

ckinnan wrote: post #14

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

Re: PHP Team Responds to Google's PHP Tips

#27

Post by DougBTX » Sat, Jun 27, 2009, 7:53 PM UTC

WilliamLP wrote: post #17

statictype wrote: post #10

Earlier quoted context omitted.

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

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.

Re: PHP Team Responds to Google's PHP Tips

#28

Post by tjogin » Sat, Jun 27, 2009, 8:51 PM UTC

gojomo wrote: post #23

tjogin wrote: post #18

Earlier quoted context omitted.

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.

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…

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?

Re: PHP Team Responds to Google's PHP Tips

#29

Post by dasil003 » Sat, Jun 27, 2009, 9:16 PM UTC

quizbiz wrote: post #19

nir wrote: post #15

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 an…

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

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.

Re: PHP Team Responds to Google's PHP Tips

#30

Post by ReturnTheGift » Sat, Jun 27, 2009, 9:34 PM UTC

patio11 wrote: post #2

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 transla…

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