Is the database not the bottleneck? Especially with the way wordpress stores "post meta data" with key and value columns it seems that the joins could get a bit ugly.
Most of the large, healthy PHP-based sites I’ve worked on spend 5-20% of their average request time in the database. Which means PHP is chewing 80-95%. Which makes PHP the slow bit.
Not because PHP is bad: That’s a pretty reasonable figure for platforms based on Ruby, Python, PHP, etc. (Less so for Java and .NET.)
It's a really good rule of thumb: If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed.
You’ve probably hit a database scalability limit, or tried to get the database to do something silly. (And hey, that’s easy to do with MySQL, which is fast primarily because it’s dumb.)
(By the way: WordPress, out of the box, doesn't spend much time in the database at all.)
Very rarely was the issue with the databases. I've had people not want to normalize data and create some generally disgusting tables and code because "joins bad"... On tables that will only ever have a few 10k records. If you have the proper indexes and queries in place, your database is just traversing btree's in memory and it will be blazing fast.
For most webapps, I/O typically should be the bottleneck. This holds especially true for wordpress, which has nothing computationally heavy to do, and is...rather liberal with the way it queries the database. Certainly the large installations I've managed spent most time doing I/O (either in the database or memcached.)
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.
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.
(Who are, interestingly enough, putting a non-PHP-based high performance dynamic front-end in front of WordPress using... WP-API.)
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).
Or doing something epicly wrong. One of the two...
(I didn't end up taking it live because HHVM did not render the page entirely correctly, but the speedup was still pretty nice.)
That doesn't discount that the database is ridiculously ugly, though.
One of the unfortunate issues with Wordpress is their continued support for outdated PHP versions. Wordpress is compatible with as far back as PHP 5.2.4, which was released back in 2007. There have been many performance improvements to PHP since the early versions of 5.x. The fact that Wordpress is eating up so much CPU on trivial CRUD logic is probably attributed to the sheer amount of technical debt/cruft in the code base, but also compounded by the need (insistence?) to support legacy systems, thus not being able to take advantage of newer features of PHP.
Indeed, only 30% of WordPress installs use PHP 5.2.
Runtime features are not a problem for WordPress users.
If you think the minimum requirement is limiting potential for optimisation, what are some relevant language and library features in subsequent versions that the WordPress team can’t use?
WordPress wasn't updating the cache; I mention that because 700ms is painfully slow, once all the JS and ads run load time can cross 2 full seconds. The cache becomes the only acceptable way to run it in production.
New Relic actually provides a breakdown of how much time was spent in each function; while I don't remember offhand what that was, there wasn't any low-hanging fruit that could be optimized.
Even a small site with a low level of traffic can bring a modest DB server to it's knees without caching of some type. It's really ridiculous but just due to the modular nature of WordPress.
It shouldn't be. If it is, it's because you missed a cache result. Even for highly dynamic sites, the DB should never be the slowest part of your app because you rarely hit it.