My Thoughts on HipHop

1] If you are using eval() and few other PHP features or want to use any of the PHP 5.3 fanciness you are out of luck, HipHop does not support those and while 5.3 support will probably happen sooner then later, eval() is unlikely to ever work. That said eval() == EVIL, so it is not a big loss, although a few templating engines depend on it.

2] To make HipHop do its magic you need to run a script to convert all of your PHP code and all of the supporting libraries to C++ and then compile it against what in effect is a C++ implementation of the Engine and supported extensions. This means anytime you need to make even most trivial of changes you will need to go through to convert > compile cycle. This btw is not an instant process and compiling things, especially C++ does take a good deal of time.

3] HipHop can only use PHP extensions specifically converted to work with HipHop, which Facebook done for the extensions they happen to use, if you need something else, you either need to convert the extension yourself, or HipHop is not for you. Since most PHP dev's probably don't have the time, skill or inclination to convert native PHP extensions to C++ variants to work with HipHop this can be somewhat of a deterrent.

4] The compiled binary can be run either on a command line or its own web server instance based on libevent, this means to use it you change how you serve content to your users, by putting a proxy or equivalent in place, so that PHP requests go to "php server" and the rest are handled via your web server of choice. Since your compiled code is effectively built-in into the web-server, it means any code changes in your PHP scripts will require a web-server restart as well.

5] HipHop does not work on Windows, since Facebook does not run its PHP on that platform and with good reason . That said it could probably be addressed with some effort, but the number of PHP Win32 devs who could do it, I can count on the fingers of one hand. So, unless MS decides to throw some resources that way, it is unlikely happen.

6] As PHP continues to evolve, divergence between "native" and HipHop functionality will definitely take place and continue to take place, remember HipHop does not use Zend Engine, it in effect has a C++ library that emulates its behaviour as far as majority of 5.2 functionality goes. This means there will be always things that work on PHP and not on HipHop and perhaps vice versa.

7] HipHop is written in C++ and converts code into C++, all of the PHP internals (extensions) and the Zend Engine is written in C and vast majority of PHP core developers are more at home with C then C++. This makes it challenging for people best equipped to take HipHop further do so, now that it is Open Source.

8] Security, while PHP perhaps does not have the best reputation for security as Steffan Esser will be happy to tell you, it is not bad by any stretch of the imagination and it is progressively getting better. This is largely the result of many people, looking at source code or just what PHP does and finding bugs and getting PHP developers to fix them, hence a massively distributed code review effort . HipHop while compatible with PHP, is really a separate implementation, with its own set of bugs and security faults, and while I am sure Facebook team done many code reviews and security audits, it does not really compare to man-years spent reviewing the "stock" PHP code.

Does this mean HipHop is bad?

By no means, as I've said before it is an incredibly impressive technical achievement that in the case of Facebook's use-case makes a lot of sense. It is just that 99.9% of PHP deployments out there do not share the same challenges as Facebook (massive, continually evolving code base and equally massive traffic), where the delivered performance increase would justify the HipHop's deployment and maintenance challenges.

Vast majority of PHP installs can gain the desired speed improvements through the use of Opcode Caching via APC, judicious use of caching via tools like memcache and good old fashioned database optimization. When profiled, most developers find that their PHP apps are typically hitting a DB bottleneck, rather then being slowed down by PHP itself. In rare instances where PHP is the bottleneck, it is typically easier to either optimize the code, or if that fails rewrite into a C extension, latter being even faster then HipHop, being native rather then converted code.

That said I think HipHop is a very helpful development for PHP community in general. For one it demonstrates that PHP can be converted/compiled into native code, which in the end is the holy-grail of performance for any scripting language. It is also Open Source, meaning people can learn from it, use some of its ideas or evolve the solution even further. Who is to say that HipHop may not one day evolve into a JIT compiler that can be installed in a form of an extension and deployed easily on ANY PHP installation. The released code also contains some other useful snippets such as some Facebook specific extensions and concepts that can be applied to the standard PHP installation, making the stock PHP (or some of its extensions) better.

From an immediate usability standpoint HipHop can be of big interest to authors of complex command line or daemon tools, that are now starting to be written in PHP, perhaps even GUI applications written with PHP-GTK. Since a lot of deployment challenges are simply not there and running a few scripts to convert and compile before execution would be of minimal inconvenience compared the obtained performance benefits. Also, given that those scripts typically use limited subset of PHP functionality they are also quite likely to work as is without the need to convert any PHP extensions to HipHop equivalents or come across un-supported functionality.