Sigh. What a difficult question. There are numerous incarnations on StackOverflow. All nearly unanswerable. The worst part is questions where they add the "in general" qualifier. Which is "faster in general" is essentially impossible to answer. And yet, the question persists. There are three rules for figuring out which is faster. And there are three significant problems that make these rules inescapable.

His three rules are:

• Languages don't have speeds. Implementations have speeds.
• Statistics Aren't a Panacea.
• Benchmarking Is Hard.

He seems to hit most of the issues with these sort of "faster" posts up front and notes that, while benchmarks can be run on a lot of different aspects about the languages, the results depend on how you slice it. His suggestion is, instead, to not try to compare the languages in a grand sense. Take each of them and compare them on specific tasks and let those results stand alone. Each of the three languages is going to be better at something than the other two.

Over the years, PHP has evolved from a script language to a programming language used in big applications with high-level architectures. As the most popular language for web applications, PHP is very fast, robust and stable by default. Coming from tiny scripts, PHP is used in large-scale web applications nowadays. In terms of business context, we need to focus on these three key factors: Scalability, Responsiveness and Resource misusage. All three factors have a high impact on hardware costs, customer loyalty and - indirectly - sales.

They mention a few ways that you can use to optimize your application's code including evaluating resource limitations, Firebug caching results and finding bottlenecks with something like XDebug.

Other great articles in this issue include:

• a look at Flex and the Zend Framework
• part one of a series on normalization (Chinese)
• using cURL to extract pages and their data
• "The Job Interview" - an insiders guide.

There's two ways to get this issue - you can either subscribe to the magazine for a year (the PDF edition is only $40 USD) or you can buy the single issue for about $5 USD.

Comparative benchmarking is tedious work. It's not hard to do, it's just no fun to set up the same scaffold every time you want to figure out how long it takes different pieces of code to execute.

To do a benchmark, essentially you need only four things: a timing mechanism, a loop to run the first case, a loop to run the second case, and a way to show the time taken by each loop.

To illustrate, he gives example code of a simple loop and the output of its timing results. But, since this is a boring example, he demonstrates something a bit more complex - something using Solar_Test_Bench and Solar_Test. The example of using these two components pits require_once and Solar's own loadClass against each other. He also includes another similar test, one comparing fopen and exploding the include path to check for a file's existence.

In the article, he looks at what accelerators are, how they work, and some of the ones that are currently out there in the market:

• APC
• eAccelerator
• Zend Platform

With the ground rules established, he breaks out the analysis into a few different rounds/categories including: support/maintenance, the accelerator's actual performance (including the code they used) and the results he discovered (all graphed out), and, finally, how they handle file updates made to the system.

In the end, there just isn't one that's a clear winner. What it really boils down to is what kind of situation you're in - Zend's option is good if you can pay for everything, otherwise, you'd do well to go with eAccelerator.