Please note that the bits and pieces of information come from various sources and things may or may not be exactly as we think they are.

In order to understand what HipHop for PHP does it is important to understand how PHP itself gets executed. In this article I will give a rough overview of the PHP execution process and make a few educated guesses in what aspect HipHop for PHP differs from there.

Based on the little information available online I'll discuss how HipHop for PHP is suitable for large businesses and what might turn out to be obstacles that are yet to remove.

The PHP execution process

PHP code can not be executed directly, a property it shares with all other scripting languages such as Python, Ruby and JavaScript. What makes PHP executable is the Zend Engine, and it does so in a two stage process.

1. The scripts are parsed and analyzed, checked for syntactical and semantical errors and if all goes well the application is transformed into byte code.
2. Since the byte code is still not executable on a CPU, it is interpreted further into machine code (that is CPU dependent) and then executed.

For most PHP applications the first parsing stage takes most of the total time. The second execution stage is comparatively fast. So in order to speed up a PHP application, most code optimizers hook into the Zend Engine after the first stage has been completed and save the generated byte code into a cache. In a consecutive call to the webserver the cache will be fed back into the Zend Engine, thus skipping the entire first stage of the execution process.

There are quite a few products on the market that behave in such a way. Zend itself offers the Zend Optimizer (now part of Zend Guard), there is eaccelerator and APC, which comes as a PECL package.

The execution process with HipHop for PHP

What sets HipHop for PHP apart from these three (and no doubt other) accelerators is that it does not act as a cache. Instead, HipHop for PHP will transform your PHP application into C++ code and compile that directly into a binary which is executable.

In that sense, HipHop for PHP is probably very similar to Roadsend PHP which also generates executable code from PHP, albeit not by transforming it into C++ first.

In essence, HipHop for PHP will get rid not only of the first stage of the usual execution stage, but also of a big part of the second stage, namely the interpretation of byte code into machine code. Generally I believe it is safe to assume that HipHop for PHP has the potential to run an application much faster than any of the previously mentioned accelerators, simply because there is less for to be done at runtime. Time will tell.

For detailed information on the internals of HipHop for PHP make sure you watch the Facebook Technology Tasting video on ustream.

Possible limitations

The requirements
The requirements to run HipHop for PHP are available online. Nothing out of the ordinary at first sight. The page claims that HipHop for PHP is tested on CentOS and Fedora. Both are venerable distributions, no doubt. But both also come without vendor support which may or may not be a problem for your organization.

Granted, companies who's codebase can actually benefit from HipHop for PHP will no doubt have a team of excellent system administrators which maintain Linux in their sleep. But those companies might also be in the situation that their customers demand a Linux distribution with commercial support, such as SLES, RedHat etc.

So this is more an organizational issue rather than a technical. That being said it is not clear yet whether or not packages will be released by other Linux distribution vendors once HipHop for PHP is out. If at all, it probably won't happen soon.

Coming back to the requirements for HipHop for PHP, it requires customized packages of libcurl and libevent, which again may or may not be an issue for your environment. Here I see the same organizational issue, but also a possible technical issue - you might be in the situation that you need the original libcurl or libevent for some other software on the server. Only a practical test will tell.

Unsupported language constructs
As with most PHP caches and compilers, a few PHP language constructs are not supported. Most commonly known is the eval() construct which is simply not available in C++. Personally I believe that eval() is a bad thing to begin with and you can get around it in almost every cases. Sadly many PHP frameworks such as TYPO3, many PEAR packages, Drupal and Joomla make use of eval().

If you're intending to run one of these through HipHop for PHP you might need to wait for an update from the community, patch it yourself, or remove the code from the system if you don't need it. In any case this is a time consuming task.

Aside from eval() a few more language constructs may not be supported or may not benefit from the compilation in terms of performance, such as call_user_func_array() and other 'dynamic' constructs like dynamic variables, dynamic includes or built-in functions like function_exists(), class_exists(), get_declared_classes() etc.

HipHop for PHP is no different from other caches and compilers in these regards, so please don't make that affect your choice. Just be aware that things might not be as easy as you'd like them to be.

No Apache?
This is speculative at this point but the Running HipHop page on GitHub seems to indicate that HipHop for PHP will not make use of the Apache webserver but instead come with its own webserver. My assumption is that this means we'll have to handle HipHop for PHP through Apache, much in the same way that we frequently do with Tomcat. This is not necessarily an issue.

The potential of HipHop for PHP

Despite the limitations I mentioned above, I believe HipHop for PHP has the potential to take PHP much further into the enterprise environment than many of the existing solutions. If it can deliver what it promises it is definitely something we will take a very close look at to give our eCommerce framework a serious performance boost.

Very high on my wishlist is to run the transformation process from PHP to C++ but skip the compilation. If that's possible I see the chance to make debugging compile errors much easier.

Consider the following scenario: You have a group of classes, each responsible for returning a specific statistic. All these classes implement the same API, as given by a common abstract class.

Now, some of these statistics are publicly accessible, others require a certain access control permission to be set.

The logical approach would be to implement a static property to the abstract class, denying access by default. Those classes that are indeed public will overwrite the static property with the correct setting and become accessible.

The property is static to gain speed: There is no need to instantiate the class, if the access control is not satisfied.

Stripped down to the bare essentials the whole set of classes to outline the issue looks like this:

abstract class StatisticBase {
    public static $acl = '0';
} // end: class StatisticBase

class PublicStatistic extends StatisticBase {
    public static $acl = '1';
} // end: class StatisticBase

class AdminStatistic extends StatisticBase {
    // default value for $acl is fine
} // end: class AdminStatistic

AdminStatistic is an implemented class that is private, indicated by the $acl property being 0. PublicStatistic on the other hand is public, hence $acl is 1.

Now before instantiating a specific class we can check whether or not the access condition is satisfied:

if ($user->isAdmin == true || PublicStatistic::$acl == 1) {
    // retrieve admin statistic...
} // end: if

But naturally this is cumbersome as soon as you have more than a handful of statistics - you don't want to add another condition to your if-statement whenever you add a statistic. So the logical solution is a loop:

$statistics = array(
    'PublicStatistic',
    'AdminStatistic'
);

foreach ($statistics as $statClassName) {

    if ($user->acl == 1 || $statClassName::$acl == 0) {
        // retrieve current statistic...
    } // end: if
} // end: foreach

Here PHP 5.2 will fail with a fatal error.

You can't access static class properties by means of using a variable for the classname. PHP 5.3 can. There is no really elegant solution for this. (If you know one, post it in the comments!)

While I'm glad that PHP 5.3 has one more OOP feature covered, It leaves me with the feeling that we still have a long way to go until PHP fully supports object orientation.

Now, if Novel would please release a PHP 5.3 package for SLES 10 and SLES 11... thank you

However, when it comes to SEO and bandwidth optimization and standard compliance many of the plugins fall short and require some additional attention. The good news is that usually many plugins are available to scratch a single itch. Picking the right one often avoids many glitches.

Social network plugins and social bookmarks

I want to reach out to people with this blog. This includes enabling my honored readers to quickly share my articles with their community through the various social networks.

TweetMeMe Button and Facebook Share are two plugins that put nifty buttons in your blog that include counters to boast about how many people shared your content. Both are really great and work perfectly, but I encountered some issues due to which I removed both from this website after a test period of a couple of days.

I had to remove the TweetMeMe Button simply because it loads content from the tweetmeme.com server which is currently very slow, thus slowing down my website as well. There is nothing the author of this plugin can do about it I guess.

Facebook Share on the other hand was removed because it uses an id="" attribute for the button it displays, even if the button is on the page multiple times. Since this is violating W3C compliance this plugin had to go, too.

In addition to that, both plugins cause my layout to look a little bit messy and 'cheap', which I try to avoid. Again, that is nothing that can be fixed by the plugin authors since it is just my personal opinion. I really liked both plugins but these minor glitches made me move on to...

Tweet This - CSS sprites

I found another nice extension for social bookmarks called Tweet This. The author Richard X. Thripp did a really great job on this, offering bookmark icons for not one but many social networks. That covers my bases.

However I enhanced this plugin slightly in order to utilize CSS sprites for the social bookmark icons. My friend Chris recently talked about CSS sprites on his blog SwiftLizard.com. Here is the concept in a nutshell:

If you display ten icons on your website the traditional way the browser has to request ten files from the server - one for each icon. Since usually browsers do only a handful of requests at a time this slows down your website. With CSS sprites however, you can utilize CSS and one single graphic containing all icons to achieve the same effect with only one image being requested. This results in website response times that are much lower, thus enabling a smoother surfing experience.

Further optimization of Social bookmarks [added]

Since I posted this article I further enhanced the way I handle social bookmarks in this blog, you might want to check that out.

WP Super Cache

The plugin WP Super Cache almost needs no introduction. Written by Donncha O. Caoimh it enables us to circumvent PHP completely and serve static content in many cases. Naturally, this is much faster. The plugin is a must for anyone taking performance seriously. WP Super Cache alone reduced the initial response of my blog (time-to-first-byte) by 80%.

iPhone and mobile browsers

As the owner of a technology related website I believe it is reasonable (and my access statistics seem to agree) to believe that some of my visitors will visit the website from a mobile device such as the iPhone or a Blackberry. While technically the layout I chose for this blog looks ok in my iPhone, there is a lot of clutter that I don't want to wait for on my mobile device.

Thankfully there is a plugin called WPtouch which displays the blog in a highly stripped down but yet good looking manner when viewed with a recognized mobile browser. Not only do mobile visitors get their content faster by removing clutter, the usability is also highly increased. Perfect.

Combining JavaScript and CSS files

Similar to what I said earlier about many images slowing down a website, the same is true for many JavaScript or CSS files. Regardless of the file type you should keep your number of requests as low as possible. With Wordpress and its many plugins that is next to impossible though, unless you want to rewrite every plugin you install.

But there is hope. What CSS sprites achieve for icons, the Head Cleaner plugin does for JavaScript and CSS files. It can combine all JavaScript files into one and do the same for CSS. Further, JavaScript can be minimized and both file types can be compressed, reducing not the number of requests but the bandwidth as well.

Image size

This is a classic. Double check the images you have on your website for size - the size measured in bytes, not pixels. If you're not sure how to reduce images byte-wise, there are online services like the one on dynamic drive which can guide you (and save you lots of manual trial-and-error time).

General rule of thumb is that a png will be smaller than a gif and images with only a few colors should never be stored in a jpg. For example the ScrumMaster badge you see on the upper right was initially a jpg of 25kB. My all means the png I use now looks identical and is only 13kB.

Results

Given all the measures above, I was able to save over 50% of bandwidth and 75% of requests on the frontpage of my blog. No matter how fast your broadband connection is, you feel the difference. Even better, the website is still W3C compliant.

When in doubt what else you can do, I can recommend registering for Google Webmaster Tools and install their Page Speed Firefox plugin. It will hook into the famous Firebug plugin and provide you with an additional tab that gives very useful hints how to improve your website speed.