Hot on the heels of the beta release for version 7.0 of the PHP language, Facebook's HHVM project -- a high-speed PHP engine -- has a new point release as well.
Benchmarks published by Facebook show performance improvements for HHVM over both its previous versions and the stock PHP engine. But many PHP packages don't take advantage of the full gamut of functionality exposed by HHVM -- or have test suites that fail with HHVM, meaning it is still not a generic replacement for stock PHP.
However, not all of that is HHVM's fault.
Must go faster, must go faster
Introduced in 2013, HHVM uses a just-in-time (JIT) compiler to speed up execution of PHP code. The increase varies depending on the application, but the latest set of benchmarks released by Facebook puts HHVM at between two and four times faster than PHP 5, and from 1.1 to 1.5 times faster than PHP 7.
Facebook Performance benchmarks for HHVM vs. various versions of PHP with many common apps. Greater accelerations are possible, but mainly with apps using asynchronous I/O rather than any changes in the PHP engine itself.
That said, anyone expecting to drop in HHVM and automatically get Facebook-like speed and scale from their PHP applications is bound to be disappointed, largely due to the way many existing PHP applications are built. In its analysis of the HHVM benchmarks, Facebook noted, "[N]one of these [tested] frameworks [Drupal, Mediawiki, WordPress] take advantage of the asynchronous I/O architecture available in HHVM (i.e., async)."
As a result, apps bound by synchronous I/O operations can get only so much acceleration by optimizing their CPU usage. At some point, I/O also has to be optimized -- and that falls to the authors of the PHP apps, not the authors of the PHP engine.
Hitting more than one wall
To support this assertion, Facebook performed its own experimental optimization of WordPress to use asynchronous database queries. The company found that such a change "can demonstrate performance gains in both RPS [requests per second] and response time." (Detailed performance numbers were promised at a later date.)
Another possible stumbling block to the wholesale swapping of PHP for HHVM: Many PHP packages, as made available through Composer, don't yet pass automated testing when run under HHVM.
The HHVM Support in PHP Projects site tracks Composer packages, and while many common options test successfully under HHVM, some work only in part -- and others don't work at all. This makes HHVM useful for running the most commonly used frameworks and apps (such as the above-mentioned WordPress), but less popular PHP apps might not be so lucky.
Over time, HHVM might achieve the most influence not by supplanting PHP but as a source of ideas for how future iterations of the stock PHP engine could be implemented. As long as the great majority of PHP applications aren't modernized, the stock engine will be most peoples' best choice.