On the Google Developers Blog (and lots of places across the web) there's a major update that Google has done for their AppEngine service - the introduction of a PHP runtime to their offerings.

App Engine 1.8.0 is now available and includes a Limited Preview of the PHP runtime - your top requested feature. We're bringing one of the most popular web programming languages to App Engine so that you can run open source apps like Wordpress. It also offers deep integration with other parts of Cloud Platform including Google Cloud SQL and Cloud Storage.

You can get more information about how to use this new feature on Google App Engine site.

While admitting that micro-optimizations aren't usually worth the time that's taken to worry about them, Gonzalo Ayuso has thrown together some array read benchmarks to show the difference, if any, in where array values are fetched.

Normally our code is coded once and executed thousands of times, and we must keep in mind that CPU time many times means money. We need to balance it (as always). But, WTH. I like micro-optimizations, and here comes another one: Checking the access to arrays with PHP.

He sets up three different options and tests the memory consumption and run time for each:

• Referencing a value from a large array outside a for loop
• Referencing a value from a large array inside a for loop
• Echoing out the value from a large array inside a for loop

Not surprisingly, all three approaches yield just about the same results. It probably has more to do with the size of the large array than how it's accessed. The fetch outside the for loop did come in slightly under the others, but not enough to worry about it.

Gonzalo Ayuso has put together an experiment related to the current OOP structure of PHP - a test working with runtime classes, a structure generated entirely when the script is executed and not predefined in the file.

Last week I was thinking about creation of a new type of classes. PHP classes but created dynamically at run time. When this idea was running through my head I read the following article and I wanted to write something similar. Warning: Probably that it is something totally useless, but I wanted to create a working prototype (and it was fun to do it).

His class is pretty basic - a "Human" object that echoes a "hello world" sort of message via a "hello()" method. He creates the classes inside of different test methods to ensure that his assertions are true. The tests check basic output of the "hello()" method, calling undefined methods, testing inheritance and a test creating and evaluating a dynamic function.

For something more complex, he creates a dynamic class that solves the FizzBuzz kat, a popular programming puzzle. You can find the full code for this and his other examples on github.

During some of his development, Christian Weiske found the tests for a project he was working on too slow for comfort and figured there had to be a way to find the root cause:

Running the specific test cases for the part of the application you're working on is easy and fast, but that does not tell you when changes in part A of the app break part B - which happened several times, and all just because I didn't want to wait 45 seconds again and again. So a solution was badly needed; tests should be as fast as possible; preferably < 10 seconds. Before being able to make the slow tests faster, I had to find out which of the 80 tests were slow.

Tools like Jenkinks give more detail on test runs, but a normal PHPUnit install won't. So, he came up with a method that uses Phing's phpunitreport task to generate extra reporting easily. Here's some example screenshots: test results summary, test detail and single page views of the same sort of data.

Shay Ben Moshe has put together a quick post today where he benchmarks array handling performance differences between PHP's native array and the newer SplFixedArray data structure that's a part of the Standard PHP Library that comes with any recent version of the language.

In PHP, arrays are one of the most fundamental data structures. We use them everywhere. They are very flexible, because they are implemented as associative arrays, and therefore let us use both string and integer keys. They are also unlimited in size, in most languages arrays are fixed-sized, but this is not the case in PHP. With that in mind, there still is a drawback. It damages performance. The solution for this problem may be SplFixedArray. But, it is not a perfect solution.

He points out two major differences - the SplFixedArray is, well, a fixed size and the fact that it can only use integer keys (no associative arrays here). He created three tests to compare the performance of the two:

• Writing data to the array
• Reading data from the array
• Getting a random value from the array

Each of these are measured in terms of runtime and/or memory usage. If you'd like to try out the tests for yourself, you can download the files needed. I won't cover the results of the tests here, though - you'll need to visit the post for that!

Ralph Schindler has put together a new post for his blog about some of the best practices for using exceptions in PHP 5.3 - specifically dealing with some of the new functionality that comes with this latest PHP version.

Exception handling in PHP is not a new feature by any stretch. In this article, we'll discuss two new features in PHP 5.3 based around exceptions. The first is nested exceptions and the second is a new set of exception types offered by the SPL extension (which is now a core extension of the PHP runtime). Both of these new features have found their way into the book of best best practices and deserve to be examined in detail.

Some of the features he talks about were pre-PHP 5.3, but the focus is largely on these new features. He gives a bit of a background on exception handling in PHP and how custom exceptions could be thrown. He then moves on to the new features - first nesting exceptions and then some about the new core exception types (found here). All that being said, he includes some code to show the dynamic/logic/runtime exceptions in action including a look at best practices in library exception handling.

Derick Rethans has posted the third part of his series looking at the garbage collection handling in PHP (the first two parts are here: one, two). In this last part of the series, he'll look at some of the possible performance impacts the garbage collection functionality can have in your applications.

In the previous two parts of this column we have explored PHP's take on circular referenced variables and a mechanism that allows to clean up this particular problem with reference counted variable tracking. Of course, the implementation of the garbage collection mechanism in PHP 5.3 has some performance impacts. In this third and last part of the column I will cover the performance implications of the addition of this garbage collection mechanism.

He looks at the two possible places that the collection could have an impact - memory usage and run-time delays when the garbage collection routine is fired off and does its job. As before, each of the topics is accompanied by bits of code and a few graphs showing the differences between handling in PHP 5.2 and PHP 5.3 as well as a handy way to get a bit more information out of PHP (using the GC_BENCH CFLAG when compiling). ,/p>

On the Drupal4Hu.com site there's a recent post with a complaint about the OOP functionality in PHP and how Drupal developers should deal with its limitations.

While I was always complaining of PHP's inability of adding a method run-time, the problem we face is that you can't replace one either. So if you do what I did in the previous post, namely use the hook-alter patten (already an addition to PHP, I must say) to override the classname, that works. However, if two modules try to do this for two different methods, you fail.

He suggests to those Drupal developers out there that, for version 8 of the popular content management system, they drop the "closed crap that in PHP is called OOP" and work to make something better, implemented themselves. Something that would make it simpler for Drupal developers to create hooks into the main system for their plugins. Be sure to read the comments for other opinions on the post.

On the SitePoint PHP blog today Craig Buckler has a suggestion on how to handle unloaded extensions in your application in case you need to define a failover.

Unless you're creating very simple applications, you will soon require one or more PHP extensions. Extensions are code libraries which extend the core functionality of the language. [...] What happens when you want to move your web application to another host or platform where a different set of extensions are configured?

Using the extension_loaded function built into PHP, you can create intelligent code that can fall back on a different technology if needed. In his example its trying to check for the GD graphics extension and echoing and error message if it's not found. The function_exists function can be used similarly.

According to this new article from the Software Development Times Facebook has rewritten the PHP runtime from scratch and will be releasing it soon as an open source project.

So, why has Facebook rewritten the PHP runtime? Because PHP is obviously too slow for their tastes. A few years ago, I had a coffee meeting with some of the folks from Zend. When they asked what I had been hearing about PHP in the market from my sources, I hemmed and hawed, then told them that I had heard people complaining about how slow PHP was.

Other sources suggest the release won't be a full runtime but instead a sort of compiler for PHP applications including an interview with a Facebook employee who drops a hint about their future plans for the language.