If PHP has a reputation as a ghetto, it's in part because of cocksure noobs like this who think they know everything and are impossible to have a rational conversation with.
You can read all about them here: http://shootout.alioth.debian.org/
There's a very obvious reason why a language may be relatively fast today and relatively slow tomorrow - namely, other languages continue to be developed as well.
And now, here's what the point of my comment is. I assume you work with PHP and are unhappy hearing that it's slow. Well, I work primarily with Ruby, which in general is even slower, so don't take offense. :)
Let's take a look at the context of this conversation. You haven't seen any evidence of its relative speed for "several years," and haven't even given the issue enough thought to discover the most obvious reason why its status may have changed, and yet in the face of somebody offering evidence (I did on the OP) are reluctant to accept the possibility that PHP is slow. I've programmed in PHP for around 10 years, starting when 3.0 was in beta up until the first few releases of 5.x, and in that time I've seen many, many PHP developers with this attitude.
This is a general problem of the PHP community: Zend has done a fantastic job marketing PHP, and PHP has been used on so many high profile projects, that developers just assume PHP is "blazing fast," when that's simply not the case.
Now, before I get attacked as a PHP hater again, let me point out that even though I prefer to work with other languages now I am by no means a PHP hater. I just recommended a PHP solution over a Ruby one to a potential client, because in their business context I thought it made more sense and couldn't in good faith sell them a technical solution that wouldn't meet their needs as well just because it used my current favorite language.
I'll also explain where PHP is quite fast. A lot of the functionality in PHP is just a very, very thin wrapper on top C library calls, and has very little overhead. This is why things like math operations are generally quite fast. Facebook's Hip-hop compiler, which precompiles PHP to C++ and then compiles it to native binary, produces code which on some benchmarks performs worse then the original PHP code because of this fact.
But the parts of PHP which aren't just delegated to C code are in general very slow. Consider, for example, a benchmark that's heavy on array traversal. Take a look at PHP compared to other languages and see how incredibly badly it performs compared to everything else:
http://shootout.alioth.debian.org/u32/benchmark.php?test=bin...
TL;DR: 16 minutes for PHP and 268.15 seconds for Ruby 1.9.
If you want to bitch about the fact that that benchmark includes the time it takes PHP to compile the code, well, then subtract roughly 0.1 seconds from PHP's time, but also do it for Ruby since Ruby's benchmark also includes compile time. Opcode caching isn't going to save you here.
Think about this for a second: what do you use more in a web development context: math operations, or array traversal? Just think how much time your web apps spend looping over database result sets. See what I mean? PHP may certainly be "good enough" but please just stop saying it's the fastest thing out there unless you can show me some proof.
If the PHP community had more of a backbone and stopped believing untruths like "our docs are the best in the business" and "PHP is the fastest scripting language" then Zend would be forced to do something about it. The fact that the language, the interpreter, and all the soft infrastructure around it are such a mess is not because Rasmus or Zeev or Andy are incompetent, it's because for years they've had such an incredibly unskeptical community of "true believers" that never holds their feet to the fire on anything. Stop being a true believer. Insist on something better. Bitch and complain if you have to. That's how to improve the programming language you love to use.
I disagreed with your comment because I didn't (and still don't) think it's valid to compare the speed of running precompiled binaries vs. something being interpreted.
Why is that not valid?
1. Java (your example) compiles to bytecode and drops the output into .class files. It only runs this compiled form. 2. PHP natively compiles to bytecode every single run. It does not save the bytecode (or cache it) by default. APC does this.
My point on my blog was that if you're going to benchmark PHP vs. C++ and call one slow in the end, you should at least try and put them on the same playing field.
Think about it this way: Could you make a real decision of which language to use for a website based on those benchmarks? No, and you (@compay) concurred that there are other factors to take into account (like opcode caching). This is why the benchmarks are irrelevant in the context of my post.
And if you still can't understand why opcode caching is irrelevant to the benchmark I cited, then you are being a fanboy.
If you have a hard time believing that your favorite language may have some performance deficiencies that could be improved then you are acting like a fanboy. Simply saying "I'm not a fanboy" doesn't disprove it because actions speak far louder than words.
I didn't refute that PHP has performance deficiencies either.
The only thing I can really say from looking at those benchmarks is that PHP is very likely a poor choice for general purpose (non-web) application development where speed is a definite issue.
When building a webapp although, those benchmarks suddenly because unclear to me because they mask the fact that byte/machine code caching is used for some, but not all languages. That feature is available for PHP, and it's called APC.
That is all.
Sorry, I guess I just assumed that because of the amount of time you've dedicated to writing about PHP on your blog, and the fact that all but one of your projects on Github are implemented in PHP. But sure, maybe your favorite programming language is one you never publish code in, and never write about on your blog. Forgive me for assuming too much. BTW, I never said there's anything wrong with PHP being your favorite language, if it is.
> You're drawing an invalid assertion based on the fact that I've been disagreeing with you.
Bravo, you've scored a point in the argument. However, you've also managed to reduce our conversation from a potentially friendly, intelligent discussion of the benefits and drawbacks of PHP to a competition to cherry pick single sentences and find the tiniest flaw in them, rather than look at the ONLY point I've been trying to make the whole time, which is that PHP's average performance on cross-platform benchmarks is not very good, and so it's not such a good idea to claim it's "maybe the fastest and most scalable scripting language" unless you have good evidence to show why the benchmarks are irrelevant.
In the course of this discussion you've lost sight of the fact that I posted a friendly, supportive comment on your post and merely pointed out one thing that I thought was inaccurate, and you've come at me with guns blazing, telling me to look into APC, which I was already using when you were probably still in elementary school. That's why I called you a cocksure noob.
> When building a webapp although, those benchmarks suddenly because unclear to me
Yep, like I said in my very first comment, I think PHP is often just fine for web apps, because its raw performance in a web context is often not the bottleneck. However, sometimes it is a problem, which is why people have invested the time into creating PHP to native binary compilers, for example. If APC solved all performance problems, do you think anybody would have bothered?
> because they mask the fact that byte/machine code caching is used for some
Stop equating Java bytecode and PHP bytecode. It's not the case that if you simply enable APC, you'll get in insane performance boost in, for example, array traversal. You'll get a significant performance boost in page request time because the interpreter doesn't need to generate the bytecode over and over again. That's it, unless you throw in an optimizer as well.
(That said, full disclaimer: I'm writing a PHP extension in a hobby project for a popular library to use that library from PHP, so in that sense I've moved closer to it again over the last 2 months).
Anyway, my main point was that you said "to point out that PHP's interpreter is in fact rather slow compared to pretty much everything else", which I still don't agree with. On straight pass-through to C calls, the overhead is a lookup in a hash table for the function name, and some wrapping of arguments into a union if need be. Arrays are slow because they're also implemented as hash tables; for high performance, one can use structures with iterators that can skip this step. But these are all just single data points; I haven't looked into the implementation of the tests you linked to, but I guess it's not that hard to find counterexamples. That's the nature of tradeoffs you make.
Your comment seemed to imply that the runtime is somehow deficient, compared to others; I'm still not convinced that is really the issue, especially since PHP is really just C with some wrappers around it. Whereas for example Python apparently does (used to do maybe, I don't know) much more bookkeeping etc for the dynamic features that enable its syntactic niceties. Advances in VM precompilation may catch up with that, but how would it make such progress that it would be faster than the straight-to-C equivalent?
Also your mention of hiphop I don't understand. When hiphop compiles something to C++, and then into machine code, it can only be slower than the original PHP code if it changes the algorithms - which are hiphop issues, not related to the speed of the runtime.
Anyway I wasn't claiming that PHP is the fastest or best documented; I just don't accept at face value your claim that PHP is significantly slower than other languages in its class on a sufficiently wide range of real-world use cases.
(for the documentation, I always liked it - most of it lists the parameters, a simple example and some corners cases, and the comments are great, of course for people who are capable of separating the chaff from the wheat. Actually I think there is still a script in the php source tree written by me that transformed the docbook docs into man page format, so that I could open the docs of the function under the cursor in a split window in vim with a single keystroke; that was in 1999 though and 'parsed' the docbook with regular expressions, so if anyone in their right mind had a look at it in the last 10 years they would've deleted it).
If you disagree with @compay, you will assuredly earn the same title.
(Compay has a karma of 1426 for comparison, and I owe him for introducing me to the PIE library for IE CSS)
Based on your comment and that you have a tenth the karma of the person you're accusing of being reactionary, I would recommend that you make an actual argument or mount a defense, and stay away from these kinds of insults.