[phpnode]

I too wish php had a widely supported compiler, but in reality it's not something that most projects require. The overhead of interpreting php is a lot lower than e.g. making a single db call. Also, in the most common usage scenarios, PHP processes only live for the time it takes to deal with each request, so how do you approach that if you're compiling your code? Keep spinning up new processes or rewrite your application code?

Regarding MVC frameworks, try Yii - http://www.yiiframework.com

[Joeri]

I wouldn't dismiss PHP's speed problems that quickly. Opcode caches typically don't speed up the actual execution, just the loading and parsing. I use zend server (with zend optimizer) and I've got PHP code that is hard CPU bound, as optimized as it can be, and still takes minutes to run to process perhaps 2 megabytes of raw data. By contrast, the exact same feature implemented in Delphi runs in less than 2 seconds, even though the code is an order of magnitude less efficient.

PHP isn't just orders of magnitude slower than JIT-ed or native compiled languages, but it has no affordances for that fact. There's no standard way to run code in the background. Zend won't start working on one either, because they sell a jobs queue as part of their Zend Server product.

Frankly, a JIT-ed PHP is the only feature I need. I appreciate the syntactic sugar added in the last few revisions of PHP, but honestly, I'd trade every new feature since PHP 5.2 for a bit more speed. With stuff like closures and traits it seems like they're working on the easy stuff instead of the necessary (but hard) stuff.

[DonnyV]

These speed charts are why I would compile Php. http://naspinski.net/post/AspNet-vs-php--speed-comparison.as... It seems worth it too me.

Thanks for the Yii link.

[phpnode]

those charts don't say whether APC is enabled, which leads me to suspect that it isn't. APC is an opcode cache that greatly enhances php performance, no one runs a high traffic website without using APC

[seanp2k2]

eAccelerator and XCache also do the same(ish) thing. APC usually helps way more on subsequent requests. While APC /can/ help a lot, it's not the magic speed bullet that some make it out to be -- if your app is a bodged mess of Joomla and stuff that you got outside developers to write for you, it'll probably still run like garbage with APC enabled.

Getting a bit off topic here, but one of the biggest performance killers I've seen is PHP devs writing Really Awful SQL(tm). Even beyond stuff like failing to use PDO and prepared queries to avoid SQL injections, if you look around you'll find tons of just really abysmal SQL. Typical problem: someone is using an oper in SQL that forces MySQL to not use indices. This absolutely kills performance and you typically won't notice it as a developer unless you're pre-populating your database with a large "real-world" dataset and doing proper performance testing.

[DonnyV]

Did not know about APC...nice. Does APC just compile it after the first time and save it in memory? Can you use APC to create a packaged compiled file?

[zombielifestyle]

bytecode caches (like APC) store the bytecode on the fly in memory. you can't create somthing like a "binary" file.

edit: at least they're not intended to create "binaries". you can probably mess around with APC and make php look and behave like a compiled language. but you won't gain any notable speed improvements beyond the on the fly caching.

edit2: you can store php projects in a jar like file, caller phar. http://php.net/phar