Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP Team Responds to Google's PHP Tips

groups.google.com

Post reply on HN
Print view View original

31–40 of 40 posts

Re: PHP Team Responds to Google's PHP Tips

#31

Post by encoderer »

CalmQuiet wrote: post #26
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…

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.

Re: PHP Team Responds to Google's PHP Tips

#32

Post by encoderer »

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?

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.

Re: PHP Team Responds to Google's PHP Tips

#33

Post by nir »

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.

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.

Re: PHP Team Responds to Google's PHP Tips

#34

Post by 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.

Re: PHP Team Responds to Google's PHP Tips

#35

Post by Shakescode »

mindaugas wrote: post #13

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?

Re: PHP Team Responds to Google's PHP Tips

#36

Post by 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.

Re: PHP Team Responds to Google's PHP Tips

#38

Post by robryan »

CalmQuiet wrote: post #26
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…

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.
Post reply on HN