It is, absolutely. And Wordpress is notoriously liberal with its queries and use of storage in relational database (unless something monumental has changed in the last year). There's a reason there are 8 million caching plugins.
If PHP is the slowest part of your application, you're probably in good shape. If your Wordpress application is slow, replacing PHP with Hack is like putting a souped up engine in a car with no gas in the tank.
PHP scaled poorly at Facebook not because it was PHP, but because it was Facebook. They would have run into the same (or worse) performance issues with most dynamically-typed languages.
HHVM was needed at Facebook because it's a dynamic app with rapidly changing content.
WordPress sites are typically static content that are perfectly fit for static caching with a CDN - it really shouldn't matter how many milliseconds you are able to save on the server if your site is only being hit once every two hours from the CDN.
The 8 million caching plugins are unnecessary when you can just sign up for cloudflare.
8 million caching plugins is a total exaggeration. As far as I can tell there's only two options: WP Super Cache (which seems to have been abandoned by the author) and W3 Total Cache which is a spammy mess of nag screens to join New Relic and MaxCDN. (No wonder it was banned by WP-Engine.) If I wasn't busy on other projects, I would take on W3 Total Cache--it's the worst UI I have ever seen and it doesn't even work. I had to mostly disable it today because my CPU went from 100% to 600% after installing it.
FYI, WP Super Cache is not really abandoned. The plugin author works for Automattic (as do I). I would say more that it has been so popular that support has been hard to keep up with and there hasn't been much focus on new features recently. Patches are always welcome: https://github.com/Automattic/wp-super-cache/
Cloudflare is - in this example - just one of the 8 million (albeit as a CDN, a far wiser choice).
Ultimately that sacrifice comes down to real-time dynamic site versus having some content be static or conditionally dynamic. None of that is a symptom of PHP as the backend (unless you have a LOT of traffic).
Yep. I double-checked that I hadn't borked the PHP install because I was surprised at the result. I'm not sure what it was doing to make the big difference since the inconsistencies with real PHP behavior were enough to write it off as a drop-in replacement, so I didn't continue experimenting much more, but it seemed promising.
If PHP is the slowest part of your application, you're probably in good shape. If your Wordpress application is slow, replacing PHP with Hack is like putting a souped up engine in a car with no gas in the tank.
PHP scaled poorly at Facebook not because it was PHP, but because it was Facebook. They would have run into the same (or worse) performance issues with most dynamically-typed languages.