Comments on: PHP Performance Best Practices

By: Ian

Ian — Wed, 30 Jul 2008 21:18:28 +0000

@James, If you have 30k LOC in one file, your concerns should be about the maintainability of your application, not performance.

Taking a speed hit in exchange for maintainability gains is a good trade-off. CPU cycles are cheap and only getting cheaper. Developer cycles are expensive and getting more so.

By: Martin Rusev Blog about web development and graphic design » Blog Archive » PHP performance tips around the web

Tue, 29 Jul 2008 08:15:23 +0000

[...] http://atomized.org/2005/04/php-performance-best-practices/ [...]

By: James

James — Mon, 28 Jul 2008 19:57:19 +0000

been looking around the web for a good article on performance tuning.

I have a script that is approximately 30,000 lines long (it’s a simulator)… I’ve recently begun to hack out logical pieces of the script and place them in separate files… as the script will run, it will include whatever applicable file is needed at that time.

I’ve read that having a massive number of includes can actually reduce performance due to file I/O delays.

At what point do the delays from the includes start to outweigh the parse time of a single large script?

By: kvz

kvz — Sat, 06 Oct 2007 16:03:30 +0000

Another article about optimizing the performance of apache & php for high traffic loads:
http://kevin.vanzonneveld.net/techblog/article/survive_heavy_traffic_with_your_webserver

By: TruePath

TruePath — Mon, 25 Jun 2007 22:00:16 +0000

So long as you aren’t modifying the arrays passing by reference shouldn’t be any faster. It is my understanding (from a comment posted in the PHP manual on references) that internally php always passes/assigns by reference adding appropriate copy on write flags so data can masquerade as a copy.

In any case it is far from clear that passing by reference results in better performance *unless* you want to modify the values in the array and have those changes show up in two places.

By: Ian Eure

Ian Eure — Tue, 06 Mar 2007 19:37:33 +0000

Hans,
Thanks for the feedback. I ran these tests a while back, and have not re-run them with PHP 5. The situation with some of these items has changed; for example, PHP 5 supports foreach by reference, which PHP 4 did not. The variability of these factors is precisely why I implore people to test different scenarios to find the best balance for their use-case.

You’re absolutely right that there is a trade-off of clarity vs. speed for string operations. It’s an individual choice as to whether it’s a win or not.

By: Hans Duedal

Hans Duedal — Tue, 06 Mar 2007 10:13:35 +0000

My studies of “string concatenation instead of sprintf()” show a 20% performance increase in favor of string concatenation. Not 100% as you mentioned. I many cases I would prefer sprintf for the clarity the syntax provides when the speed increase is no more than in average 20%.
This is testet on PHP 5.2.1 running in CLI mode on Ubuntu.

By: LeoTech » Blog Archive » Javascript Smorgasboard

LeoTech » Blog Archive » Javascript Smorgasboard — Thu, 08 Feb 2007 20:40:26 +0000

[...] In addition to the PHP Performance link from yesterday, I just added four related to Javascript to the sidebar. [...]

By: TechnoPetr » Blog Archive » PHP Smorgasboard

TechnoPetr » Blog Archive » PHP Smorgasboard — Mon, 05 Feb 2007 16:50:26 +0000

[...] Atomized | PHP Performance Best Practices [...]

By: Ian Eure

Ian Eure — Sun, 30 Oct 2005 00:04:05 +0000

“Single-quotes aren’t really any faster than double-quotes. That’s a myth.”
No, it’s a myth that they are significantly faster, which I don’t claim.

“So if you actually benchmark these, you’re not going to find much different between ‘’ and “” for any real-world situation where both are appropriate.”
You’re right - there isn’t much difference, but single quotes are slightly faster. I ran some comparative tests a while back - I suppose the situation may have changed with PHP 4.4.0/5, but it was faster at the time.

And why use double-quotes if you don’t need to parse variables in the string anyways? I see this as akin to using preg_match() or ereg() where a strstr() would work just as well. If you don’t need all the features something offers, why use something that offers them and is slower, even if only very slightly so?

I do mention that you should profile your code. Anyone who tries to optimize without examining the impact will not get good results. None of this stuff is absolute; everything depends on your setup. Perhaps I should have stressed that more.