This is particularly interesting because PHP's runtime was rewritten for 5.1 back in late-2005 (on top of 5.0's Zend Engine 2.0 improvements in mid-2004).
And is PHP really considered "pokey"? Sounds like this guy is making stuff up because I get execution times of >0.01 seconds on my micro-framework.
PHP is dirt slow. When you look at the implementations of Lua or Python (which have approximately the same design as PHP), its about 4-5 times slower. Note this is only in the interpreter -- lots of the library code is written in C, which makes the difference somewhat less relevant.
The implication is that writing code that uses PHP's built-in libraries is pretty fast, but the more you write in PHP itself, the slower it gets. For example, my impression is that Yahoo isnt really written in PHP - its written in C patched together using PHP.
The Zend engine was "rewritten" for PHP 4, PHP 5, and to a certain extent for PHP 5.1. I guess it wasn't a complete rewrite because the legacy code from about 10 years ago is still in there. Anyway, its still dirty, badly written, slow, and very very badly commented. Hacks abound (and not the good kind).
This is a point I always have trouble impressing on people. They do a simple benchmarks on a tiny code base that pulls some data from the database, spits out some data, and they compare and PHP seems to be lightning fast.
The problem is that because it's interpreted at some point PHP slows down in proportion to the size of your code base. A small app runs really fast, a big app with 100,000 lines of code will kill your server unless you modularize it really really well - which harder than it seems, because the more modularized you make it the more separate "includes" you end up with in different files and then you come to realize that including a lot of files itself is a problem. And the nature of PHP's very loose coupling tends to lead to code that is nearly impossible to do large scale refactoring on once you have gone too far down the path.
I work on an application that has a very thin PHP layer that performs some simple web services that are the back end for a pure Java web app. Amazingly, when we load test it, the PHP part is the bottleneck, burning CPU like crazy just parsing all our files ... over ... and over ... and over. The java code meanwhile, while theoretically doing far more "work", is completely bored. We will probably look at using an accelerator of some kind or maybe just rewriting all the PHP in another language.
If your problem is parsing time, just use an accelerator. APC is the standard and best integrated.
On the other hand, if you have an opportunity to switch out PHP for something better (read: nearly anything), you should. Otherwise it might grow to a point that you can't remove it.
"For example, my impression is that Yahoo isnt really written in PHP - its written in C patched together using PHP."
Yahoo! is a company, not a single application. Not everything at Yahoo! is written in PHP, but the vast majority of Yahoo! properties do use PHP heavily on the frontend, and not just as a way of patching together C extensions.
Well, if you use APC then that's all irrelevant. It's the equivalent of creating .pyc files. I never got the impression it was slower in actual execution, though.
The argument being made was that the PHP runtime is 4-5 times slower than Python and that PHP only looks as fast as it does because of the C libraries. This is simply untrue and the OP wasn't able to back it up. Cores don't come into it.
A quick stumble through the Language Shootout suggests using PHP instead of C might make you need, oh say 10 to 100 times as many servers. So there is room for improvement.
Of course if your workload is not dominated by script running CPU time then it doesn't really matter. Even then, until the cost for extra servers and their management exceeds the engineering cost to recode, add servers.
I get execution times of >0.01 seconds – hope you aren't planning to handle more than 50 transactions per second.
It all depends what kind of world you live in. I know people that use their hard disks for booting and loading caches and that's it. If one query in a hundred requires a seek they will not keep up. Most of the rest of us could happily fork a CGI PHP for each request and not notice.
I guess you stumbled past the places where the benchmarks game website links to "Overall Performance: PHP is rarely the bottleneck (HTML slides)" http://talks.php.net/show/drupal08/7
Well, with quotes like "it is simply not a language designed for the sorts of workloads that Java and .NET are" I'm not sure of the author's technical level.
Also, his comparison of Zend's "folks" (which ones? Founders? Execs? Sales people?) to "gestapo officer looking for a spy: "What? Who said that? Who said it was slow? Tell us their name!"" isn't too apt - they'd probably like to know who complained about PHP performance, so they can offer them their products/services, rather than silence them somehow.
And is PHP really considered "pokey"? Sounds like this guy is making stuff up because I get execution times of >0.01 seconds on my micro-framework.