I think some of this discussion has been from very different interesting angles. Let me explain how I see and use PHP.
PHP is the frontend of your backend. It is not your backend in any sizable system. By that I mean that PHP is not the place to play around with large data sets. Databases, Cassandra, Hadoop, memcache, etc. serve that purpose. If you need functionality on top of those backend systems that manipulate millions or even thousands of rows on an individual request, then you need to build it in something other than PHP. It also isn't for forking background processes, hence we have technologies like Gearman. PHP punts the hard stuff to technologies designed to handle those tasks and instead focuses on the glue layers. In the early days of PHP (1994-1996) I saw PHP as primarily a C API for extending the web server without needing to know the internal workings of the web server. The macro-templating language was a cute feature that let you expose the functionality you built in C as a set of template tags. The Web grew so fast and was initially mostly ignored by lower-level C developers so the people tasked with building web sites didn't have the background to write C code against the PHP API which caused the focus to shift away from the API to bunch of canned tags that people commonly needed/requested. This hasn't changed that much over the years. The templating language has matured quite a bit and is now powerful enough to write extremely complicated things in it. But you still shouldn't write a database in PHP. This isn't about server costs. It is about choosing the right tool for the right part of the job. A Javascript library for the client-side frontend, PHP for the server-side frontend, C/C++ for your middle-layer and an appropriate datastore behind it all and you can build amazing things with PHP. The largest destinations on the Web today are written exactly like this. This doesn't mean we shouldn't try to optimize PHP, and you will note that APC is scheduled to be included in PHP 6, but there is always going to be significant overhead incurred by a scripting language. PHP 6 needs more room to store strings, for example, because we live in a Unicode world. And yes, there are obviously ways to reduce the overhead with custom datatypes, but it makes things more complicated because, as I said, PHP is glue. By having a single datatype that all the extensions understand, everything can talk to everything. Once you start moving away from the single zval approach towards different datatypes for different purposes, you have to retrofit all existing extensions to teach them how to treat these new datatypes and it makes the already too-complicated extension API even more complicated which would hurt the glue aspect of PHP. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
