My Take on Facebook's HipHop for PHP

Disclosure: Since Facebook Inc. is a customer of, I might be considered biased. For the purpose of this blog posting, consider me taking off my " hat" and putting on my "PHP Community hat".

HipHop for PHP

The Announcement

Yesterday Facebook Inc. announced "HipHop for PHP", a source code transformer that turns PHP 5.2 code (minus some features) into C++ code that can then be compiled with g++, for instance, to a regular binary.

The Summit

If you are following some key PHP community members on Twitter, you may have learned that a couple of weeks ago Facebook invited a select few to Palo Alto, CA to give them a sneak peek at the technology.

Terry Chay has a great summary of this event (including photos):

At the Summit
Facebook, Palo Alto, California

This "private summit" is one of the reasons why this announcement was preceded with a lot of rumors. I am not really interested in rumors (or conspiracy theories, for that matter), so I will focus on the technology and its impact here.

My Opinion

I am very happy — both as a "programming language geek" as well as an Open Source enthusiast — that Facebook Inc. decided to open source their solution to their problem. Understanding this is crucial:

  • Facebook had a problem.
  • Facebook found a solution for their problem.
  • Facebook decided to share their solution with the PHP community at large.
    Kudos for that!

Now what was their problem?

Facebook has a large code base that would take a long time (one to two years by my estimation) to refactor or rewrite in either PHP or another programming language to achieve the performance improvement that Facebook was looking for. During this time of refactoring or rewriting, Facebook would not have been able to innovate.

In the past, Facebook tried to achieve performance improvements by contributing to PHP as well as APC. Many PHP deployments benefit from this contributions today, but for Facebook they were simply not enough.

From this perspective it makes a lot of sense to dramatically change the way that they deploy and execute their PHP code: without major modifications to their existing code base they are able to run it with a CPU usage reduced by 50%:

"Facebook sees about a 50% reduction in CPU usage when serving equal amounts of Web traffic when compared to Apache and PHP.

Facebook's API tier can serve twice the traffic using 30% less CPU."

This is a sustainable solution for them as it allows them to benefit from PHP's advantages such as shorter development cycles and lower training costs — while at the same time, thanks to HipHop, reducing their data center costs.

What others are saying ...

Terry Chay is spot on when he summarizes the impact of HipHop in his blog posting:

"Arguing against PHP for performance reasons no longer holds water. [...]

In practice, you can get the advantages of having a scripting language without operational costs. [...]

HipHop is a showcase. With it the PHP world can point to Facebook as being the busiest site built in a scripting language in the world."

Stefan Priebsch (also with makes the point that you need to rethink your PHP development before you can dance to the HipHop beat:

"HipHop executes PHP code bypassing the Zend Engine, so there is no guarantee that a program will behave exactly alike on PHP and HipHop. More and better automated unit and integration tests will be required to allow you to compare the results on PHP and on HipHop, and determine whether deviations are to be interpreted as a bug, or can be tolerated."

I could not agree more: As there is a real build — including a real compilation — with HipHop, best practices such as coding standards and continuous integration will be even more important.

In conclusion, I would like to welcome "HipHop for PHP" to the PHP ecosystem. Yes, it is not a solution for a problem faced by 99.9% of the PHP deployments out there. But this does not make it less interesting in any way.

One more thing ...

PHPUnit runs on "HipHop for PHP", details can be found in the wiki.