The truth is I have a love-hate relationship with PHP. The linguist in me abhors PHP sprawl and the pragmatist in me adores PHP’s simple execution model and practical ubiquity.

Upon returning to PHP this September it felt both familiar and unsettling. The feeling of returning to the town you grew up in. Frameworks, like familiar faces, looked the same as when you last saw them just heavier and a bit more mature. Nowhere as spectacular as the framework heroes of other towns like of Pythonville or Rubyfordton. City council was still making unorthodox decisions like enforcing backslashes for namespaces. Yet downtown was booming- many of the greatest internet successes of the world had since established themselves here: Facebook, Flickr, Yahoo!, and others.

So I set out to create an open source framework called "Recess!" which will be available on GitHub in preview form "any day now".

I just recorded its first screencast that dives into how it Recess! handles routing. Interested to hear your thoughts:

http://www.recessframework.com/screencasts/routing/index.htm...

(disclaimer: the flash video may be slow to load - until which you'll see an empty black page)

In deployment mode that routing tree is serialized and cached. Only a single (matching) controller is then touched. Unserializing the data structure is extremely fast and finding a match is roughly an O(log n) operation.

Using a pure-PHP framework (a template system built in a templating language) leads to pitiful rock-bottom performance -- orders of magnitude slower than any of the popular templating systems that exist for Perl, Python, or Ruby.

I'll start: http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

Don't sweat it, Ruby's only 50% slower!

Proportional results on a faster machine: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...

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.

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.

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.

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.

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)

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.

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

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

!