printf(“Hello Word”);

It may decline even further this time! ;)

*Sorry my english!

Love your language, use it for everything web-related, but I have to say that you and I see a different PHP. For small sites, RAD is an ideal solution (where performance isn’t a big deal), and large sites can afford to optimize the site to match its growth.

I’m not sure how you can keep from repeating yourself without the use of a Front Controller, which is really a combined router and bootstrap/common.inc file. Every application that wants routing to be more flexible than Apache can offer moves the responsibility to routing PHP code. The most necessary elements (first encountered and most frequently used) logically must be top-most parent element to avoid being called at all (which would require being called more than once).

Looks like you missed the Drupalcon this year. Here’s the video:
http://www.archive.org/details/simple_is_hard

And a short transcript:

1. Rasmus: “Tell me where the Web is going, and I’ll tell you what the future of PHP is”.

I can only tell you that web applications are getting more an more complex, and that PHP is getting slower (unless you create a “hello world” application and tweak your laptop).

2. Rasmus: “PHP is only useful for the presentation layer”.

So, are you saying it’s kind of useless nowadays? Considering that Python and other scripting languages can do the same, and can be used not only for the presentation layer?

3. Rasmus: “Facebook and Yahoo don’t scale because they use PHP, they scale because they use C++ libraries”.

It can’t get worst than that… for us of course.

4. Rasmus: “PHP frameworks are ridiculous slow”.

Thanks for the tip Rasmus. I guess that’s why everyone is using Django now, right? According to you it’s faster than all the PHP framework together.

5. Rasmus: “I don’t like frameworks”

Yeah well, low-level programmers don’t like frameworks, but keep in mind that web developers do, and they need them.

6. Rasmus: “The front-controller pattern goes against the web architecture”

Yeah right, that’s why Rails and Django are becoming so popular right? Come on man, put yourself together and start supporting PHP developers. You are killing the language!

An approach like “everything is a object” (where symfony is almost) is also in my oppinion not a good thing.

We should be looking at ALL things with moderation… frameworks included… Even OOP…

Note that Rasmus’ setup has less than a 1% difference between static HTML and a PHP equivalent, so what you’re seeing is about 28-times worse difference than Rasmus noted (and about 1.5-times better than the difference I’m seeing on Amazon EC2 ;-). I don’t know if Rasmus was using Suhosin or not.

It appears to me that the operating environment has a huge impact on how much the opcode cache improves performance. It seems the lesson here is that opcode caching on Amazon EC2 in a “hello world” exercise does not gain you that much o of a benefit. An additional lesson is that benchmark numbers are simply not comparable between different operating environment (or, that some operating environments are more responsive than others, which intuitively makes sense to me).

Per your last point (3), note that none of the “hello world” tests (either Rasmus’ or mine) involve the use of a database.

HTML: 4944.03 [#/sec] (mean)
PHP: 3584.90 [#/sec] (mean)

So, PHP output is roughly 72%. This is with debian unstable, apache 2.2 prefork, dynamic PHP 5.2.6-3 w. Suhosin. 0.9.6.2, and Xcache.

I can very easily imagine that with a bit more performance-friendly tweaking, like static PHP, not having a ton of extensions, etc, that number will come significantly closer to 90%, and very possibly past it.

I have to agree that properly written PHP is almost never the bottleneck. The bottleneck is usually one of these three: 1) pointless overhead, 2) other forms of poor programming (whether procedural or object-oriented), or 3) the database.