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.

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.

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.

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.

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!

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.

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>]]> Mon, 13 Sep 2010 11:22:42 -0500 http://www.phpdeveloper.org/news/15010 http://www.phpdeveloper.org/news/15010 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.

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.

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.