Some days ago there was a blog post regarding php exception performance in 5.4 and the numbers got reported all over the place. The actually numbers are secondary. The main point is: Don't trust "random" stuff on the Internet when thinking about improving your application performance. You always need to measure things for your self and take care doing so! I've initially trusted the benchmark myself and disgraced the whole post saying: "Well yes, exceptions are slower than if statements but nice that they got faster".

He includes some results with a bit more standardized testing - one run with both 5.3 and 5.4 using XDebug and another with it turned off for both. His results make sense, if you think about them:

So what we learn from that? Running stuff with debugging tools is slower than not doing that. That's why we don't use xDebug in production.

Facebook did more for PHP: they also created XHProf, a PHP profiler with a (supposedly) easy-to-use HTML interface, designed to pinpoint exactly where your bottlenecks are appearing, so that you can optimize at every stage in the pipeline. [...] If you haven't tried XHProf, you might want to look into it. Installation apparently requires a little nudging, but Nick Lewis just posted a full, practical guide to benchmarking and performance tuning your PHP and MySQL, using XHProf (as well as other techniques) -- a very nice overview of many common bottlenecks and how to open them up.

There's also a link to some Drupal 6 benchmarks that shows how it has helped that project (including both small and large improvements).

A while ago, Fabien asked me to have a look at porting one of Twig's slowest methods, TwigTemplate::getAttribute(), into a PHP extension. It is a complex method that does a lot of different checks and look-ups. Fabien's benchmarks showed that this method was responsible for quite a large amount of time. On top of that, it didn't seem that it could be optimised any further as PHP code itself.

He points to the twig-ext extension that's a reworked version of the "getAttribute" method from the tool and the performance gain (about 15%) it gives. Compiled templates will automatically call this new method in the extension. This update has already been merged into the main Twig repo.

Code coverage tells you how much of your code base is actually being tested by your unit tests. It's a very useful feature, but sadly, it slows down PHP's execution quite a lot. One part of this slowdown is the overhead to record the information internally, but another part is because I have to overload lots of opcodes. (Opcodes are PHP's internal execution units, similar to assembler instructions) They are always overloaded even if code coverage is not used, because it's only safe to overload them for the whole request.

These changes were from a combination of contributions from Taavi Burns and a new ini setting that will allow you to enable or disable the code coverage in XDebug. Benchmarking shows a good amount of time reduction in coverage runs - dropping anywhere from a few seconds to over a minute. He also mentions the idea of "modes", shortcuts to predefined settings for different types of reporting (like "profiling" or "tracing").

When maintaining or running a website , Webmasters need to keep in mind that one of the pertinent issues they will need to focus on is :Website Testing, which is not only vital for the website itself but for the user as well and one should not overlook its importance. [We have] collected some vital and free website testing tools which will help Webmasters in testing their sites thus saving users to conduct time consuming needless searches in finding the best resources pertaining to Web related tools and info.

Among the tools on the list are services like:

• Load Impact
• Browser Mob
• Host Tracker
• Built With
• CSE HTML validator

Most of these resources are free services, if not then they have a trial where you can see if it's a good fit.

People like micro-optimizations. They are easy to understand, easy to apply... and useless. But some time ago, while reviewing pull requests for Twig, I read an interesting discussion about the performance of the ternary operator in PHP (thanks to @nikic for the investigation). Do you know which [example] snippet is the fastest (of course, they do exactly the same)? The right answer is: it depends.

He notes that it's all about the data being worked with. As some of his tests show (testing code included) there does end up being a difference between using it on a small and large dataset. After investigation, it was found that the ternary operator copies (copy-on-write) the value versus an "if" that just evaluates. He also mentions the new "?" version of the ternary syntax in PHP 5.3, but notes it still suffers from the same issue.

There are so many PHP frameworks that it can be hard to keep track of them all. Some are already very popular, while others are relatively new and unknown. [...] Of the seven criteria [of a good framework], this article will examine only the speed and performance.

They define their structure for testing - hardware and software - as well as some basic settings like number of connections, disabling of caching and these sample files for each of the frameworks. You'll have a see the rest of the post for their results, though.

In previous article I measured the performance of HipHop for PHP by performing some tests downloaded from the shootout.alioth.debian.org website. Unfortunately the test list was incomplete. Only six tests were selected to avoid potential incompatibility issues with the HipHop compiler.

In this new post he provides the results for two more tests: regex-dna and k-nucleotide. He outlines the testing platform and shares the results of testing some pretty basic scripts. His results were interesting and found that some operations the HipHop compiler actually slowed down.

Here are some points that come to my mind when talking about performances, scalability, PHP, ...First of all, there are many aspects/questions that are to consider : configuration of the server (both PHP, MySQL, and system) ; you might get more help about that on serverfault, I suppose, PHP code, database queries, using or not your webserver? Can you use any kind of caching mechanism ? Or do you need always more that up to date data on the website ?

He goes on to give tips about using a reverse proxy (like Varnish), using an opcode cache, caching data as well, profiling and optimizing SQL queries. He finishes it off with a more specific look at Kohana and how you can use some of its built in tools to accomplish these same goals.

I was looking at the way view helpers work in ZF2 and thought it would be more convenient if we altered the syntax a little. A side-effect of the change was that we'd have to use call_user_func_array, which is perceived as slow. I thought I'd whip up a simple test to find out how much slower it would be over a direct method call.

He includes the sample code he used to benchmark the request times between the two versions measured by microtime. In his results he saw a difference of almost five seconds between the same code running on 5.3 versus 5.2 (according to test runs on his laptop).