My somewhat glib comment was meant to point out that even had PHP been very fast back when PHP hate was a popular past time it would still have been hated for other reasons.
Ruby was (very) slow back then (notably and measurably slower than PHP, Python, or Perl) and people still loved it. The warts on PHP that got the most bad press were rarely related to performance.
So, yes PHP used to be slower than it is today, by a lot. But, speed wouldn't have immunized it against the criticism leveled against it. All the effort going into fixing performance for PHP coincided with fixing some of the bigger warts of the language, as well...so much of the hate for PHP has dwindled in recent years.
The fact that people building for the web are much less often required to work in PHP also reduces the hate.
It was low performance, but not slow, its simple model meant it was performing enough for the task (DB IO was the bottleneck most of the time).
Since PHP5, the lead team made progress into making it solid. And in PHP7 some eastern/russian guy hacked the VM a lot. Adding new traits and improving memory usage and performance a lot too.
The "hatred" comes from old days (v3,v4):
- massive inconsistency in naming
- global side effect was a norm
- bugs, bugs, bugs
Combined with the nascent web boom, tons of new kids (that includes me) started having fun with html/php. A large mass of the web was written with it, carrying all the bad design decisions in forms of security bugs and impossibly bad code.
ps: I audited one famous wordpress plugin and it was 10 pages long of redundant code in 3 big loops, dead code everywhere, commented code released in production. All this to add a few links here and there.
It's not necessarily a performance issue, unless you're Facebook (traffic wise) you might never worry about that, but it's more about the developers who use PHP[0] it's a mixed bag of below junior level to senior level developers. It's hard to know which type of codebase you will get your hands on until you do. There's other issues I personally have with it, though I use it if it's not code I can easily reinvent without investing way too much of my own time on it e.g. a forum or a blog engine.
"unless you're Facebook (traffic wise) you might never worry about that"
Facebook hasn't spent a lot of time worrying about their choice of PHP either. Facebook's primary language is Hack, a mostly compatible derivative of PHP. Prior to Hack (~2014) Facebook used traditional PHP, which they reimplemented a couple times for performance reasons. It seems that Facebook has spent its time worrying about how NOT to leave PHP.
Makes one wonder about the value of this daily new programming language era we're in at the moment.
> I thought everyone hating PHP ( also) because it was slow
Most of the replies here are stating that PHP is fast. It can be for these kind of benchmarks.
But, it does have the reputation you're suggesting. That reputation, though, is based on the old CGI model. Most php apps are built in a way that all of the initiation and setup code is run for every single request. That makes it comparatively slow.
Some PHP apps get around that by using a shared memory cache, like apcu, to box around that. That helps a lot, but isn't the same as a typical golang or node.js app where startup code is truly run once, and new requests go through a much shorter path.
All of that, though, is less a "language" thing and more of a runtime thing. You can, for example, use Facebook's HHVM+Proxygen and run PHP code in the exact same way as node.js.
php7 was threatened by hhvm and was completely rewritten by keeping backcompat. It's now the fastest major old scripting language. js and luajit are in the very fast ballpark, php in the middle and the other 3 far behind.
PHP also has the best language features and IDE integrations, the only remaining problem is the legacy stdlib and devbase. Ruby with an inliner and method cache would catch up, but I don't see it happen. Python is doomed by its architecture. Perl has a faster interpreter loop, but data structure bloat and similar dev problems as the other 2.
pypy changed not only the vm, but also the internal data structures. It's totally different.
pypy's problem is that is only optimizes loops and often called functions, not the general interpretation, as e.g. PHP7 or lua did.
For normal, simple small scripts it's not that big a benefit, and you loose all the extensions, (though that's being worked on).
That has been less true for the last few years: C extensions are still a concern, although many of the major ones work now, but I've had a significant number of programs run faster simply by using pypy. It's a full JIT compiler and one nice area that improves is regex handling so all of my log-related work got faster with zero effort.
The means that a lot of rather bad (inexperienced?) programmers use it, which means there is a lot of bad PHP code out there.
People see that bad code and assume the language is bad.
The language has some warts and inconsistencies, and people are eager to point them out as justification for their hate. But for real programming most of them hardly matter.
this is something a bit naive - basically all dynamic languages have the same low barrier and can produce the same crappy code, see for example javascript or ruby (with RoR). Python too, considering the fact that it's used by a lot of people that their main job is not software engineering.
The biggest difference between PHP and the other dynamic languages, though, is that PHP came out with pretty popular stuff like wordpress, joomla, magento or drupal that they all share crappy code coz they all have a large codebase started before PHP managed to fix some stuff starting from version 5.3
That comparison is complicated: it's definitely easy to drop a .php file on a server but once you start talking about frameworks, using a newer version than your OS distribution shipped, adding C extensions, etc. it's easy to find counter-examples, and the Go proponents are not wrong to observe that deploying a single file is easier than either.
This is also becoming less of a distinguishing factor in the container era where the answer for a number of cases is “Extend a base Docker image”.
At least PHP offers that option at all, and it's well-supported and well-documented. It's also very easy. Good luck doing the same with any other language.
If you really, really try it's possible in Python, C# and Java too, but ... wtf.
Note that I didn't say it wasn't a selling point for PHP. It's just that I can count on no fingers large PHP projects I've seen where deployment is still that simple – and that's generally not a problem because with modern tooling (e.g. Ansible) and deployment options (e.g. containers) you're under less pressure to make that a deciding factor for your application.
As slow as it might be to develop something from scratch in c++, perhaps. But, if you're using a framework and/or good libraries, all of that underlying work and ecosystem is standardized for you. Now, the ecosystem with things like Symfony are really great.