HHVM is an open-source virtual machine developed by Facebook and designed for executing programs written in Hack and PHP. It offers increased performance for PHP, most of the time. You can already use HHVM in ServerGrove servers by using our packages.
We have read numerous blog posts and articles suggesting to use HHVM when running Composer. If you are not familiar with Composer, check out our Composer 101 article.
Since Composer needs to perform some heavy computations in order to resolve the dependencies of a project, it makes sense to use HHVM. However, the heavy computations are mainly done when running composer update, or when the composer.lock file has not yet been generated so this is where you will see most of your gains in execution time.
Here are some tests while working with a Symfony2 Standard Edition project.
Running composer update with HHVM takes ~4 seconds:
$ time hhvm composer.phar update --prefer-dist --no-scripts Loading composer repositories with package information Updating dependencies (including require-dev) Nothing to install or update Writing lock file Generating autoload files real 0m4.362s user 0m3.540s sys 0m0.168s
While running the same command with PHP takes almost 11 seconds:
$ time php composer.phar update --prefer-dist --no-scripts Loading composer repositories with package information Updating dependencies (including require-dev) Nothing to install or update Writing lock file Generating autoload files real 0m10.768s user 0m9.692s sys 0m0.180s
Running composer install
So running composer update with HHVM is clearly a benefit. It will save you a lot of time, and the larger the number of dependencies, the more time you will save.
However, we found that when running composer install with HHVM takes longer than doing it with PHP. This is especially important when using Composer in deployment workflows, as usually you would run install and not update and you will have a composer.lock file.
The reasons why HHVM is slower than PHP when running composer install are still unclear. There is some time lost while doing the JIT warmup, and HHVM really shines when it can run optimized and compiled bytecode, which is not the case with command line scripts, but we believe there is more than just the JIT warmup, as tests show several seconds of difference. We gained some performance by disabling the JIT (hhvm -v Eval.Jit=0), but it is still slower than PHP.
Composer install with PHP:
real 0m2.547s user 0m1.190s sys 0m0.919s
Composer install with HHVM:
real 0m4.905s user 0m3.010s sys 0m1.337s
Composer install with HHVM and JIT disabled:
real 0m3.062s user 0m1.604s sys 0m1.158s
You can run the same tests by using the shell script in this gist. Please share your findings with us.
We have seen many posts and articles suggest that you should create an alias in your shell configuration so you always run Composer with HHVM. Given the fact that HHVM is not always faster than PHP, we don’t think this is a good idea yet. We expect the HHVM team to improve the performance and at some point this article will become obsolete. Until then, consider this before you go all the way HHVM.
Also, we would like to know what others think and we encourage to try this test with your project. Share with us what you find.