Bullshit, you linked to rankings (one where PHP's wart is omitted), not results, and your 'faster machine' is many times slower. It's not really so simple:

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

They go back and forth, but on the meteor contest (which is the alioth people's favorite) Ruby's delta is 260, while PHP's is 36,117 (!!)

My main point was that templating frameworks written in PHP are WAY slower than using PHP directly, as you're doing a ton of pointless string operations. Benchmarks back this up, even ROR is >= the PHP frameworks (especially when there's no opcode cache): http://www.avnetlabs.com/php/php-framework-comparison-benchm...

PHP is really fast when you use it as a straight templating system, but once you start writing real applications in it, writing your own high-level PHP inside PHP, it is the slowest thing around.

"writing your own high-level PHP inside PHP"

If you're smart, like smarty, you'd compile your high-level PHP into PHP and then you're not doing a ton of pointless string operations.

> PHP is really fast when you use it as a straight templating system, but once you start writing real applications in it, writing your own high-level PHP inside PHP, it is the slowest thing around.

This is what I find most people underestimate about PHP - it scales badly in a slightly unique sense: it scales badly with application size. The problem is incremental and therefore hard to deal with.

You start off with one small PHP file. It's wicked fast! 3 months later you have a dozen PHP files and most of them include some common library scripts that are shared between them. It's still fast. A year later your library scripts have grown and grown. Each PHP file is now including 4 - 5 library scripts and those themselves are getting up to thousands of lines long. You try to refactor things but the problem is PHP is such a dynamic and loose language and has such poor abstractions that it's really hard to do that successfully. So soon just to spit some HTML on the page your poor application is interpreting thousands of lines just to render some simple HTML. You look at FastCGI but your cheap web host doesn't support it and then you realize that there are a host of compatibility issues on top that you never thought about when you started that will cause problems.

By the time it is mature your PHP application is slow because it is spending all its time parsing the thousands of lines of poorly structured PHP and very little actually rendering HTML.

Finally, you look at PHP accelerators like Zend etc. and realize that you're going to have to pay for a commercial solution and the free stack you thought you were building with is not actually free any more and you see that even then there are a bunch of compatibility problems. And then you wish you had built with python ... or java ... or groovy ... or ruby ... or anything else but PHP.

It's the poor support for modularization and abstraction combined with the interpreted nature of the language that leads to this.

That's a load of FUD and a fabricated horror story. Computationally intensive business logic should be implemented as a C/C++ extension in any case because PHP is still essentially a web language and a glue language. Rasmus Lerdorf, PHP's creator, has stated as much.

Any claim that PHP can't scale is at this point a dead letter, as are more dated claims that Java is too slow, etc.

But as soon as you get into building extensions to mod_php, you've lost everything that's great about PHP: the deployment story / execution model.

And if you have the capability and good reasons to build your own extensions, deployment probably isn't much of a concern. But building and loading extensions into PHP is not very difficult, assuming dependencies are already met.

Well, I think you completely missed my point, since I didn't anywhere say that PHP can't scale in the sense you are talking about.

While we're at it, PHP is pretty bad for desktop GUIs and artificial intelligence...

blasdel > but on the meteor contest (which is the alioth people's favorite)

Which of the "alioth people" told you the meteor contest was their favourite?

blasdel > you linked to rankings (one where PHP's wart is omitted), not results

If it's their favourite then why do you think "the alioth people" don't include meteor contest in their ranking?

Yes, compare language implementations directly one-against-another for all the benchmarks.

As thomasmallen is so keen on the old Pentium 4 machine, compare PHP with Ruby Core 1.9.0 ;-)

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...

(Disclaimer - Obviously the benchmarks game webpages are written in PHP)

In many ways, PHP is itself a framework. Only an idiot would make a high-profile website using ZF or CakePHP. Good luck using straight Ruby for a website.

Please don't force me to link to some of Terry Chay's work. There's a very good reason that PHP is used for many high-profile websites whereas Ruby is not.

thomasmallen > Proportional results on a faster machine...

What makes you think an old Pentium 4 machine is faster than a quadcore Q6600?

I assumed the units to be in seconds, but after looking closer, I can't find a good definition of the units used here. It's the mean of a series of ratios, but the base unit is not on this page. A combination of the lower totals and the fact that one machine was running Gentoo led me to believe that this machine was the faster of the two. (End backtrace of my thoughts)

thomasmallen > A combination of the lower totals

Don't you need to know about the numbers that make up those totals?

Like if on Pentium 4 the nbody input value is 20,000,000 but on Q6600 the nbody input value is 50,000,000 ...

thomasmallen > the fact that one machine was running Gentoo led me to believe that this machine was the faster

!

If the results are proportional between trials and are well-accepted (which these seem to be), I'll admit that I'm less interested in the specifics. If I saw aberrations, I would dig deeper, and I'll admit that my analysis was not rigorous.