3 ms·

I've been looking at ways I could squeeze more performance out of my long running PHP jobs (wasn't my decision to write it in PHP) at work and HHVM was very att

I've been looking at ways I could squeeze more performance out of my long running PHP jobs (wasn't my decision to write it in PHP) at work and HHVM was very attractive due to the extreme focus on JIT optimizations. Unfortunately it doesn't seem like any major framework still supports HHVM officially. Even artisan dies when I try to run it unfortunately. At one point I remember everyone pushing to support HHVM, that effort seems to have stopped. Does anyone know why this happened? Was this just performance improvements of PHP 7? JIT optimizations like this would really shine in longer-running use cases.

jjeaff 8y ago
It has to be php 7. In lots of comparisons, php 7 was performing close to or better than hhvm. And that was before the performance improvement of 7.1 and 7.2
bastawhiz 8y ago
> Does anyone know why this happened? I was at Box at the "peak" of the HHVM hype. Honestly, the biggest thing that doomed HHVM in my eyes was lack of macOS support. You simply couldn't run it on your MacBook. Invariably, that meant you had to have a VM somewhere running it, and that made debugging compatibility issues really difficult. Finding and reporting issues was a grueling process and made it almost impossible for most folks to offer meaningful contributions. When PHP 7 was announced, all the attention that was on HHVM was split between HHVM and the official Zend solution. Folks didn't want to take up HHVM support if PHP 7 turned out to be amazing. IIRC, Etsy–who employ(s|ed) Rasmus Lerdorf–was a major holdout and drove a lot of mindshare away from HHVM. By the time HHVM got to a point where it was "reasonably good" to work on, PHP 7 was out. And the performance was pretty much comparable for most workloads. Nobody really ever cared about Hack. Nice things like compiling your PHP code into a sqlite database (I forget what they called it) was really hard to do for a codebase that didn't start on HHVM or used many dependencies. I remember bumping into some unfortunate performance issues around regular expressions and spooky Unicode support bugs. The benefits weren't really compelling and the drawbacks were hard to overcome. At the end of the day, it was just bad timing (or, you could argue "too little too late") and being developer-unfriendly. Getting your Drupal site moved to PHP 7 was an infinitely simpler choice than getting it running on HHVM, even if HHVM had a 20% perf advantage.

jjeaff 8y ago

It has to be php 7. In lots of comparisons, php 7 was performing close to or better than hhvm. And that was before the performance improvement of 7.1 and 7.2

bastawhiz 8y ago

> Does anyone know why this happened? I was at Box at the "peak" of the HHVM hype. Honestly, the biggest thing that doomed HHVM in my eyes was lack of macOS support. You simply couldn't run it on your MacBook. Invariably, that meant you had to have a VM somewhere running it, and that made debugging compatibility issues really difficult. Finding and reporting issues was a grueling process and made it almost impossible for most folks to offer meaningful contributions. When PHP 7 was announced, all the attention that was on HHVM was split between HHVM and the official Zend solution. Folks didn't want to take up HHVM support if PHP 7 turned out to be amazing. IIRC, Etsy–who employ(s|ed) Rasmus Lerdorf–was a major holdout and drove a lot of mindshare away from HHVM. By the time HHVM got to a point where it was "reasonably good" to work on, PHP 7 was out. And the performance was pretty much comparable for most workloads. Nobody really ever cared about Hack. Nice things like compiling your PHP code into a sqlite database (I forget what they called it) was really hard to do for a codebase that didn't start on HHVM or used many dependencies. I remember bumping into some unfortunate performance issues around regular expressions and spooky Unicode support bugs. The benefits weren't really compelling and the drawbacks were hard to overcome. At the end of the day, it was just bad timing (or, you could argue "too little too late") and being developer-unfriendly. Getting your Drupal site moved to PHP 7 was an infinitely simpler choice than getting it running on HHVM, even if HHVM had a 20% perf advantage.