I had become used to writing my PHP code in a simple text editor (jEdit, if you’re wondering), so it had been awhile since I’d enjoyed the luxuries of project-wide code completion, code refactoring, and a full debugger. All of these and more are available in NetBeans 6.5.

NetBeans includes autocomplete not just for built-in functions…

but also for functions defined elsewhere in your project and included libraries:

In both cases, NetBeans picks up on phpdoc comments in your code and uses them to display pop-up documentation along with its autocomplete suggestions.

Once you select a code completion for a function or method, NetBeans assists you in filling in each parameter. When you’re done filling in one parameter, hit Enter to automatically move to the next parameter.

NetBeans also comes with PHP code templates for developers who like to set coding speed records. For example, type fnc and then hit the Tab key. NetBeans will expand it into a full function declaration, and prompt you to fill in a function name, before placing your cursor in the function body:

Because having complete phpdoc documentation for your code makes coding in NetBeans so much easier, NetBeans will even assist you with writing your documentation! Place your cursor immediately above a function declaration, type /** and hit Enter. NetBeans will automatically generate a phpdoc comment with placeholders for each of the function’s parameters and its return value:

NetBeans’s editor has plenty of other nice features, like variable name refactoring. When your text cursor is on a variable name, all other occurrences of that variable are highlighted in yellow. Type Ctrl+R and you can edit every occurrence of that variable name at once, to instantly rename it throughout the file:

And of course you can ⌘-click (Ctrl-click on Windows) on any variable, function, or class name to jump immediately to the place where it was declared—even if it’s in another file of your project.

NetBeans 6.5 combines all this PHP editing power with full support for server-side debugging with the XDebug PHP extension. You can set breakpoints in your scripts and step through your code line-by-line, inspecting the values of variables as you go.

Of course, writing PHP applications is more than just PHP code. You have to write HTML, CSS, and JavaScript code as well. When you do, you’ll be pleasantly surprised to find the same level of support for these languages built into NetBeans too! And when a single file mixes these languages together, NetBeans handles it all seamlessly.

If all those code editing features weren’t enough, NetBeans 6.5’s other core features combine to complete the experience. Built-in support for version control systems including CVS, Subversion, and Mercurial (with others, like Git, available as free plug-ins) is especially welcome, with colored bars along the sides of your code to indicate lines that you have changed since your last commit.

NetBeans isn’t a toy for learning Java anymore. These days, it’s a powerful, multi-language development environment that’s free for the taking. If you work on sizable PHP projects and you’re not using an IDE like NetBeans, you might be surprised at how much time a tool like this can save you!

You can learn about NetBeans’s PHP support and download the IDE from the NetBeans PHP Development page. And if you’re interested in following the new PHP-related features that are being worked on for the next version of NetBeans, be sure to follow the NetBeans PHP Blog.

So, as a proof on concept, I wrote a script to parse the function traces from xdebug and use this to process a php source-file, and inject docblock comments, with @param and @return tags. I had to combine the dynamic analysis (function traces) with some static analysis, to be able to collate different sub-types into their supertype, which made the whole deal a bit more complicated than first anticipated.

There are still some room for improvement, but last Thursday at the local php meetup, I demo’ed the project and it’s now available through github.

The usage is split into two steps. First you run the code, using xdebug instrumentation to generate a trace. I’ve created a wrapper script to make this simpler. Just invoke the php script with trace.sh foo.php, rather than php foo.php. This will run the script as normal, while generating a trace in the file dumpfile.xt.

The intention is to use the tool together with an existing test-case. If you don’t use unit tests, you can just put a simple integration test together; The important thing is that the script should get around in all corners of the code, to generate a good basis for the analysis.

The next step is to analyse this data and use it to generate the docblock comments. This is done with the tool weave.php. You’d likely want to call weave.php multiple times (For each file in your project, that you want to generate documentation for).

Here’s an example, to show the process:

We’ll start with a very simple file, without any docblock comments:

<?php

class Foo {
  function stuff($x) {
    return 42;
  }
}

class Bar {}

$f = new Foo();
$f->stuff(new Bar());

The first step is to run the file, using trace.sh:

$ /path/to/php-tracer/weaver/trace.sh foo.php
Running script with instrumentation: foo.php
TRACE COMPLETE

Next, we’ll weave the documentation back into the file:

$ /path/to/php-tracer/weaver/weave.php foo.php foo.php

And that’s it .. Our file now looks like this:

<?php

class Foo {
  /**
    * @param Bar
    * @return integer
    */
  function stuff($x) {
    return 42;
  }
}

class Bar {}

$f = new Foo();
$f->stuff(new Bar());

The implementation is memory-efficient, rather than cpu-efficient, which means that it’ll work with large code bases, but it will take some time to process.

However, these functions have a certain privilege in that they can access private/protected variables. This is not something that can be circumvented in plain PHP (save through some exotic extensions, which I’d rather not rely on). It seems that 5.3.0 may introduce a functionality in the Reflection API, but nobody knows when 5.3.0 will be out.

So I realised that it is possible to serialize any object to a string, which will include private and protected variables alike. All I had to do was then to parse the serialized string, and I’d gain that arcane insight. One would perhaps assume that such a parser already exists. Maybe it does, but I couldn’t find it (I did find a Java implementation though). The format is fairly simple though, so I spend half a Sunday afternoon on it. One very nice bonus, compared to print_r is that the format handles recursion, which is very handy
for dumping the output in a presentable form.

So, without further ado, here’s the code:

< ?php
/**
* Exports variable information, including private/protected variables
and with recursion-protection.
* Since this is built upon PHP serialization functionality,
unserializable objects may cause trouble.
*/
class XrayVision {
  protected $id;
  function export($object) {
    $this->id = 1;
    list($value, $input) = $this->parse(serialize($object));
    return $value;
  }
  protected function parse($input) {
    if (substr($input, 0, 2) === 'N;') {
      return array(array('type' => 'null', 'id' => $this->id++,
'value' => null), substr($input, 2));
    }
    $pos = strpos($input, ':');
    $type = substr($input, 0, $pos);
    $input = substr($input, $pos + 1);
    switch ($type) {
    case 's':
      return $this->s($input);
    case 'i':
      return $this->i($input);
    case 'd':
      return $this->d($input);
    case 'b':
      return $this->b($input);
    case 'O':
      return $this->o($input);
    case 'a':
      return $this->a($input);
    case 'r':
      return $this->r($input);
    }
    throw new Exception("Unhandled type '$type'");
  }
  protected function s($input) {
    $pos = strpos($input, ':');
    $length = substr($input, 0, $pos);
    $input = substr($input, $pos + 1);
    $value = substr($input, 1, $length);
    return array(array('type' => 'string', 'id' => $this->id++,
'value' => $value), substr($input, $length + 3));
  }
  protected function i($input) {
    $pos = strpos($input, ';');
    $value = (integer) substr($input, 0, $pos);
    return array(array('type' => 'integer', 'id' => $this->id++,
'value' => $value), substr($input, $pos + 1));
  }
  protected function d($input) {
    $pos = strpos($input, ';');
    $value = (float) substr($input, 0, $pos);
    return array(array('type' => 'float', 'id' => $this->id++, 'value'
=> $value), substr($input, $pos + 1));
  }
  protected function b($input) {
    $pos = strpos($input, ';');
    $value = substr($input, 0, $pos) === '1';
    return array(array('type' => 'boolean', 'id' => $this->id++,
'value' => $value), substr($input, $pos + 1));
  }
  protected function r($input) {
    $pos = strpos($input, ';');
    $value = (integer) substr($input, 0, $pos);
    return array(array('type' => 'recursion', 'id' => $this->id++,
'value' => $value), substr($input, $pos + 1));
  }
  protected function o($input) {
    $id = $this->id++;
    $pos = strpos($input, ':');
    $name_length = substr($input, 0, $pos);
    $input = substr($input, $pos + 1);
    $name = substr($input, 1, $name_length);
    $input = substr($input, $name_length + 3);
    $pos = strpos($input, ':');
    $length = (int) substr($input, 0, $pos);
    $input = substr($input, $pos + 2);
    $values = array();
    for ($ii=0; $ii < $length; $ii++) {
      list($key, $input) = $this->parse($input);
      $this->id--;
      list($value, $input) = $this->parse($input);
      if (substr($key['value'], 0, 3) === "\000*\000") {
        $values['protected:' . substr($key['value'], 3)] = $value;
      } elseif ($pos = strrpos($key['value'], "\000")) {
        $values['private:' . substr($key['value'], $pos + 1)] = $value;
      } else {
        $values[str_replace("\000", ':', $key['value'])] = $value;
      }
    }
    return array(
      array('type' => 'object', 'id' => $id, 'class' => $name, 'value'
=> $values),
      substr($input, 1));
  }
  protected function a($input) {
    $id = $this->id++;
    $pos = strpos($input, ':');
    $length = (int) substr($input, 0, $pos);
    $input = substr($input, $pos + 2);
    $values = array();
    for ($ii=0; $ii < $length; $ii++) {
      list($key, $input) = $this->parse($input);
      $this->id--;
      list($value, $input) = $this->parse($input);
      $values[$key['value']] = $value;
    }
    return array(
      array('type' => 'array', 'id' => $id, 'value' => $values),
      substr($input, 1));
  }
}
?>

There are at least two known issues with this technique. The first is that resources are serialized into integers. For a dump, this doesn’t really matter, since a resource is meaningless outside the running process. The other problem is with objects that implements __sleep. Since this function may have side-effects, you can potentially mess up your program for objects that use this feature. In my experience, it’s a seldom used functionality anyway, so it doesn’t really bother me that much.

Since the template can’t contain any view-logic, it ends up in a separate place (In PHP code). This makes the separation between presentation and logic airtight, which was the main idea of template engines in the first place. Another benefit is that since there is no string-level manipulation, it is virtually impossible to inadvertently get injections-type security breaches.

The template may be unaware of the view-logic, but the opposite can’t be said. To bind values to the template, the view-logic needs to be aware of the internal structure of the template. This means that if the template changes, so must the view-logic. To decouple this dependency, we need some kind of abstraction.

Luckily it just so happens that there is a very convenient mechanism for that; Element id’s can be used to address central nodes in the markup. They do however have the rather annoying limitation (For this use), that they must be globally unique to the document. A better candidate then, is to use classes (The HTML attribute - I’m not talking of PHP classes) to address elements.

The really nice thing about using classes is that it’s very unobtrusive to the markup. One will have to add classes, but since they would have to go on central elements in the markup, they would be prime candidates for reusing as fix points for CSS rules and for Javascript code. Instead of being superfluous markers in the HTML code, they actively help to write better markup.

That sounds good in theory, so to see how it holds out in reality, I mocked together a small prototype. Even with a very limited API, it has a remarkably good expressiveness:

Simple variable binding

$t = new Domling('<p class="hello"></p>');
$t->capture('hello')->bind("Hello World");
echo $t->render();

<p class="hello">Hello World</p>

Switching a block out

$t = new Domling('<p>Lorem Ipsum</p><p class="message">Hidden message</p>');
$t->capture('message');
echo $t->render();

<p>Lorem Ipsum</p>

Putting it back in

$t = new Domling('<p>Lorem Ipsum</p><p class="message">Hidden message</p>');
$block = $t->capture('message');
$block->bind();
echo $t->render();

<p>Lorem Ipsum</p>
<p class="message">Hidden message</p>

And looping over a block

$t = new Domling('<ul class="links"><li class="link"><a class="anchor" href="#">title</a></li></ul>');
$links = array(
  'Sitepoint' => 'http://www.sitepoint.com',
  'Example' => 'http://www.example.org?foo=bar&ding=dong');
foreach ($links as $title => $link) {
  $t->sequence('link', 'links')->bind(array('anchor:href' => $link, 'anchor' => $title));
}
echo $t->render();

<ul class="links">
<li class="link"><a class="anchor" href="http://www.sitepoint.com">Sitepoint</a></li>
<li class="link"><a class="anchor" href="http://www.example.org?foo=bar&amp;ding=dong">Example</a></li>
</ul>

If you’re curious, you can get the full source code for the above examples from here: http://php.pastebin.com/f76ba8d70

But please mind that this is just a proof-of-concept; There are probably a few quirks that should be ironed out before this could be used in production.

The gold standard solution is to convert everything to utf-8. Since utf-8 covers the entire unicode range, it is capable of representing any character that latin1 can. Unfortunately, that’s a lot easier to do from the outset, than with a big, running application. And even then, there may be third party code and extensions, which assume latin1. I’d much rather continue with latin1 being the default, and only jump through hoops at the few places where I actually need full utf-8 capacity.

So after some thinking, another solution dawned on me. To be fair, hack is probably more descriptive than solution, but nonetheless. The idea goes as follows:

• Use latin1, but serve pages in utf-8, encoding it at output.
• Embed utf-8 strings within latin1, and somehow don’t encode it (But still encode everything else).

Simple, eh?

Latin1 on the inside, utf-8 on the outside.

When rendering HTML pages, it is trivial to capture the output with an output buffer and pipe it through utf8_encode. The page is thus served in utf-8, even though everything internally is latin1. Not much gain in that, since it still restricts us to use the range of characters covered by latin1.
We are actually already doing this, simply to reduce the number of problems for external services communicating with our system. In particular, XmlHttpRequest defaults to utf-8, regardless of the page’s encoding.

In essence, the following snippet exemplifies:

// declare that the output will be in utf-8
header("Content-Type: text/html; charset=utf-8");
// open an output buffer, capturing all output
ob_start('output_handler');
// when the script ends, the buffer is piped through this functions, encoding it from latin1 to utf-8
function output_handler($buffer) {
  return utf8_encode($buffer);
}

Embed utf-8 within latin1.

This is the tricky part. Instead of simply piping the entire buffer through utf8_encode, the string can be parsed so anything between a set of special tags (Eg. [[charset:utf8]] ... [[/charset:utf8]]) is left as-is, while the rest is assumed to be latin1 and encoded with utf8_encode as before. This ensures full backwards compatibility, while allowing real utf-8.

Let’s modify our output-handler from before:

header("Content-Type: text/html; charset=utf-8");
ob_start('output_handler');
function output_handler($buffer) {
  return preg_replace_callback(
    '~\[\[charset:utf8\]\](.*?)\[\[/charset:utf8\]\]~',
    'utf8_decode_first',
    utf8_encode($buffer));
}
function utf8_decode_first($match) {
  return utf8_decode($match[1]);
}

And that’s it. We can now embed full utf-8 strings within our otherwise latin1-encoded application, by wrapping it with [[chaset:utf8]]. To make things a bit more readable, I added a helper function:

function utf8($utf8_encoded_byte_stream) {
  return '[[charset:utf8]]' . $utf8_encoded_byte_stream . '[[/charset:utf8]]';
}

And we can now construct a string as simple as:

echo utf8("blÃ¥bær") . "grød";

To produce the output: blåbærgrød

note: As pointed out by Kore, it would be a problem if the delimiter itself (Eg. [[charset:utf8]]) is part of the data. To remedy this, it would be safer to use a more unique delimiter. You could simply replace charset:utf8 with something that is unlikely to ever happen. It’s still not completely bulletproof, but it’s good enough for most practical uses.

Handling input.

You may or may not know this, but when submitting a form, browsers send back data in the same encoding as the page was served. Since our application is predominantly latin1, we need user-input to be latin1, to keep BC. So all input must be decoded from utf-8 to latin1. This is simple enough; We just have to pipe all user-input ($_GET, $_POST etc.) through utf8_decode. Since we already run with the latin1-on-the-inside-utf-8-on-the-outside scheme, this was already in place in our case.

This does however give a problem when the user needs to submit utf-8, as our users would need when replying to mails. So in these places, we would have to explicitly access the “raw” string, through an alternate mechanism. In our case, we needed to modify our http-request wrapper, but since this is extending the API, there is no BC problems.

With the advent of PHP6, perhaps such hacks won’t be necessary in the future, but for now this gives a working, unobtrusive solution.

Just a short background, Rasmus Lerdorf is the creator of PHP and still continues as a core developer to the PHP project.

PHP frameworks

In his address he choose to highlight PHP frameworks (Drupal was not spared) and how poor they are at performance. Not only are they slow, but their "jack-of-all-trades" attitude leads developers down the wrong path by not using what is best for the job. He continues on by stating that PHP developers really need to think about performance for not only scalability reasons but for green reasons. If programs were more efficient it would cut the number of data centres and would reduce energy needs as a result. In our newly emerging age of energy awareness this does become an important aspect and I am glad that he is raising awareness.

Back to frameworks, he started by discussing a database heavy Twitter mashup that he created. This does a lot of database calls and a lot of behind the scenes work. By hand-tuning it he was able to get on the order of 280 req/sec. By comparison and simple HTML page with nothing but "Hello World" served by Apache is just over 600 req/sec. Okay, stage is set (by the way, this was tested on his local machine).

Hello World

How do PHP frameworks score on the "Hello World" test? No database calls, just the framework being used in its native tongue to output Hello World. The results were not too good, one of the fastest got just over 120 req/sec, the slowest was 8 req/sec. This is a dramatic difference and of course highlights his argument for performance. Where did Drupal score? Right above 50 req/sec. So not the greatest, but he did make the point that Drupal is not really a framework in the traditional sense. It is a web content management system that can be quickly extended.

So, are there any frameworks that don’t suck? Rasmus did mention that he liked CodeIgniter because it is faster, lighter and the least like a framework.

How to make PHP fast

"Well, you can’t" was his quick answer. PHP is simply not fast enough to scale to Yahoo levels. PHP was never meant for those sorts of tasks. "Any script based language is simply not fast enough". To get the speed that is necessary for truly massive web systems you have to use compiled C++ extensions to get true, scaleable architecture. That is what Yahoo does and so do many other PHP heavyweights.

RDF, Semantic Web and the Monkey

RDF in Drupal. Rasmus made a special point of highlighting the importance of embedding structured metadata into the page. RDFa allows you to embed data into your web pages and also lets you create custom vocabularies, or even better, reuse existing vocabularies. Why would you want to do this? Searchmonkey will go out and index this content and open up a rich search API to allow you to do intelligent queries. Well beyond what is possible with traditional search.

Along with rich search you also get enhanced search results. I have blogged about this previously so take a look. It is really cool stuff and I will be discussing it in much more detail over the course of the conference.

Pitching the Semantic Web

What if all Drupal sites had embedded RDFa tags? Well, for one, Yahoo would be very happy. It would play directly into the strengths of Yahoo’s new Semantic Web strategy. They are trying to do interesting things with semantic data but of course they need data — the classic chicken and egg thing.

Rasmus mentioned that Yahoo’s semantic data store can scale to the size of the web so the invitation is open.

The future of Drupal

This is where my focus at Drupalcon is, driving the adoption of semantic technologies within Drupal — I feel that the momentum here will make that a reality. There is a lot of interest, a Semantic Web BoF session was stacked with people with some cool ideas…

More to come.

But a problem I came across several times was the sheer complexity of recursive element conversion — <code> becomes <jsvalue> (or one of a dozen similar elements), <a> becomes <xref> … and that’s all simple enough; but each of these elements might contain the other, or further child elements like <em>, and as we walk through the DOM so the incidence of potential recursion increases, until it gets to the point where my brain explodes.

There’s a limit to how much recursion I can get my head around — or rather — a limit to how much I’m prepared to get my head around before I just go the heck with this, why can’t I mangle it as text with regular expressions!?

Unfortunately there doesn’t seem to be a way with PHP DOM to get the text equivalent of any arbitrary node, but we can do that at the Document or DocumentFragment level; so with a little toying-around I came up with a way to leverage that capability and make it work at the Node level.

So for example, let’s begin with this XML:

<?xml version="1.0" encoding="utf-8"?>
<root id="introduction">
	<div class="section">
		The fundamental data type is <code>Node</code>
	</div>
</root>

We have a reference to its DOM saved to a PHP variable called $xmldom. And we want to parse it so that the <code> element becomes a <jstype>, and the <div class="section"> becomes simply <section>, all without affecting the rest of the document.

Here’s the complete code to do it, which I’ll then talk through stage by stage:

$node = $xmldom->documentElement->firstChild;

$doc = new DOMDocument();
$doc->loadXML('<xmltext/>');
$node = $doc->importNode($node, true);
$doc->documentElement->appendChild($node);
$xmltext = ereg_replace('^.*<xmltext>(.*)<\/xmltext>.*$', '\\1', $doc->saveXML());

$xmltext = ereg_replace('<([\/]?)code>', '<\\1jstype>', $xmltext);
$xmltext = ereg_replace('<([\/]?)div[^>]*>', '<\\1section>', $xmltext);

$node = $xmldom->createDocumentFragment();
$node->appendXML($xmltext);

$xmldom->documentElement->replaceChild($node, $xmldom->documentElement->firstChild);

In the first step we get a reference to the element we want to work with, and save it to $node.

In the second step we create a new document, and use loadXML() to create a placeholder root node (the loadXML method converts text input to XML, and is one of the cornerstones of our process). Next we import the original node into that document, then use saveXML() to convert the whole document to text (the saveXML method converts an XML document to text, and is as critical as loadXML() for what we’re doing here). The text output is parsed using ereg_replace to remove the outer contents of the document (its prolog and root node) so that we’re left with a text equivalent of the original input node.

In the third step we do whatever text-based mangling we need; in this case it’s simple element name conversions, but it could be anything.

In the fourth step we want to convert our parsed text back into XML, and we do this by creating a document fragment, then using appendXML() to load the text and have it converted to XML (the appendXML method does the same thing as loadXML(), but it doesn’t require an entire document to be created).

Finally, in the fifth step we merge the processed XML back into our original document. The document fragment has the original document as its owner, so we can simply use the replaceChild method to replace the original node and its children with the processed version. (Whenever a document fragment is added to a document, only its children are actually added, the document fragment itself is discarded; DocumentFragment is a virtual construct and never actually appears in a document.)

Both the first and the final step are arbitrary — we could work with an entire document, or just a single node, and edit our referencing and merging statements accordingly. Or we could build a method from the inner steps, which accepts $node as an argument (and maybe an array of replacement expressions), and returns the processed node at the end:

function mangleXML($node)
{
	...
	
	return $node;
}

While we’re at it, Steph Fox have dutifully been writing up summaries of php-internals discussions on a weekly basis since the beginning of time. If you just want to get the headlines, it’s an informative read.

Have a nice summer.

PHP is designed for the web. You could plug vanilla Ruby or Python into a web server and get up and running pretty quickly. But, at least at a basic level, you’d want a framework to deal with common issues of web development. In PHP, you just get started. PHP and Apache work out request data, output handling and more, right out of the box. (PHP also masters deployment.) David Heinemeier Hanson, the creator of the Ruby on Rails framework, calls this the immediacy of PHP.

Now, consider the “average” PHP frameworks. They help you handle request data, manage your output, control app flow - essentially, extending PHP’s inbuilt functionality. They are, therefore, PHP frameworks on the PHP framework. PHP provides a vast array (pardon the pun) of functionality out of the box. But when you want to do things your way, it gets out of the way, and this is really important when building anything beyond a simple database frontend.

How many PHP applications in wide distribution are built on a third-party framework? MediaWiki? No framework here. Wordpress? Not here either. Drupal? You get the idea. Each of these applications have their own framework, inasfar that the developers built a structure for their code that suited what they were trying to create. These three, and the countless others, clearly did something right - MediaWiki even powers one of the world’s top 10 websites. And when building these “frameworks”, PHP helped them along the way.

Sure, Cake, Symfony, CI - they all help you build PHP applications. But unlike a Ruby framework or a Python framework, coding is perfectly tolerable without them. Of course, most developers tend to create their own framework as they go along - I call this PHP’s DIY framework mentality, where you build the last level in your stack, and by extension you know exactly what’s going on under the hood.

This comes back to the oft-cited “best tool for the job” argument - but by being a “half framework” of sorts, PHP simply helps you within a web context. I’m sure Rails is great for countless applications; Ruby syntax helps a little too. But beyond the basics, the language becomes increasingly irrelevant, and a framework will force you to build your app according to design decisions made by the original developers. On the other hand, PHP allows you to quickly put together your application the way you want, helping you with the web-based aspect, and without having to break the language/framework to achieve your goals. Essentially, PHP is the web layer without the framework baggage.

Twitter recently had some downtime that could be attributed to its use of Ruby on Rails. Now, there’s nothing wrong with Ruby, or Rails. But Twitter is a messaging system, RoR is an application framework. Could Rails be worked around to suit Twitter? Maybe. Could Twitter have avoided these problems if they’d used PHP? Probably. Twitter’s developers have noted they weren’t quite expecting the site to be so succesful. If they had built it in PHP, they would probably have encountered other (similar) problems earlier on, rewritten the entire app while it was still feasible, and built a powerful system that could scale just fine (likely with the messaging platform in C). Using PHP could have helped, not as a language with syntax and libraries as such, but as a web development platform that gives developers the freedom to architect their systems as they want. (They could also have tried Erlang.)

So the next time you’re on the lookout for a PHP framework to build your killer app on, consider using the best framework of them all: PHP. It will give you the freedom to achieve what you want, how you want, with results. A quick hack? Check the manual, it could be a one-liner. A massive distributed messaging platform? Full steam ahead, build it your way. For everything in between, there’s a multitude of options, but if you have the time, PHP is all the framework you need.

When it comes to optimizing PHP for performance, there’s no end of resources available, and no end of conflicting opinions either. Everyone seems to have their own approach to writing “fast” PHP code; using single quotes, avoiding require_once() and using isset() before is_array() are some of the most common. But with reliable benchmarks thin on the ground, how do we know if any of these techniques - often touted as “performance best practices” - actually deliver benefits? Chris Vincent’s new PHP benchmark suite at PHPBench.com aims to “set the record straight” on PHP performance techniques, with a simple, comprehensive view of how various approaches actually stack up.

The benchmark suite covers all the usual bases, taking a simple task — like iterating over an array — and speed testing almost every possible way to achieve it. Most importantly, however, Chris takes raw numbers out of the spotlight and instead focuses on how the options compare with each other. Each test takes the fastest technique as the base value for execution time; all the other options are measured as percentages in relation to this. For example, foreach($aHash as $val) has script execution time of 558% compared to while(list($key) = each($aHash)) $tmp[] = $aHash[$key] with 100%.

The test scores are also generated live; refreshing the page will produce a slightly different set of results. Chris uses the header of the relatively uncomplicated results page to recommend refreshing a few times, just to ensure consistency and to avoid a one-off impact on any particular test. Personally, I’d have preferred the tests be carried out in a controlled environment and regenerated every time a new test is added; anomalies don’t help anyone and live benchmarking offers little real benefit besides operational simplicity. The code for each test is supplied for transparency.

His current set of tests are very comprehensive; no less than 13 tests compared the performance of various echo and print calls, with enough variety to check for any usage scenario. He’s also accepting suggestions for new tests. Most importantly, however, many of his tests help identify the value of best practices. For example, PHP is often criticised for the vague results of == comparisons; the control structures tests show us that not only is === safer, it also takes about 2/3 as long to execute.

While most of the tests show trivial performance differences, there are some interesting results. For example, iterating over an array and modifying each element is 100 times as fast using while(list($key) = each($aHash)) than a simple foreach ($aHash as $key=>$val), while array_keys() is about 20 times slower than while(list($key,$val) = each($aHash));.

The next step, of course, would be to download the test suite to your local machine or server and run the tests yourself, to see how the factors of your production environment affect the results; Chris aims to make this possible in the near future. Many of the techniques listed are clearly going to be either memory-efficient or CPU cycle efficient, and the limits of your infrastructure will determine which way you want to go before scaling out. Nevertheless, managing bottlenecks in your code can really help you get the most out of your servers — after all, if you can achieve something 100 times as fast, why not? — and PHPBench.com could become the definitive reference on PHP performance.

Update: Many commenters have noted issues with the usefulness and reliability of the tests. It’s important to consider Chris’ intentions while creating the site, as he’s described in the comments. With all the “use this syntax because it’s slightly faster” posts, PHPBench.com was built to see if there is any real material benefit to using a particular syntax; most of the tests show that there clearly isn’t. I’ve done a few tests of my own and seen similar results, but if something looks amiss, feel free to point it out to Chris. The site is not trying to identify immaterial performance benefits from e.g. single quotes vs. double quotes. Moving further, PHP Bench could be used to measure algorithm performance and other more intensive procedures; for now, the basic syntax tests simply reflect the potential of the system. Hopefully this clears things up.