> Having 8 cores with only 1G of ram would be a weird server config. A single socket quad-core with hyper-threading and 2GB RAM for a 32-bit webserver is not weird. Not everyone is Yahoo where you can just throw money around.
> For Mr. "everyone has 8GB of memory and tiny little data sets" Lerdorf, > I could point out that reducing the average zend_op size and placing > strings close to other op data will also make execution faster, due to > the improved CPU cache hit rate. I don't think PHP has as much support as you think it does. There is no big supporter to fund a real development drive like that. I doubt anyone does I1/D1/L2 cache profiling for PHP. PHP doesn't ship with an optimizer, byte code cache, or JIT. Rasmus had the idea that it should do simple things and be easy, and if you were going to do anything else, then you should have the money to do so. Fair enough really. Kinda reminds me of Firefox and its speed and memory usage. Machines have lots of RAM, so lets use it, blah, blah, blah. When they finally decided to do mobile phones, they realized what a mess their startup times were, what a hog it was with memory, etc. They even do *some* cache profiling now! I'll never use Fennec, but happily use the results in Firefox. You should see the careful work that went into Google's V8. > But most of the time, the act of optimising will take longer than just > compiling and running the code, because you have to make decisions about > whether something can be optimised and the best way to do it. Yeah, like no one should cache or JIT a web page. No loops. The use pattern is to just look at a web page once and then the next. I think Microsoft still says that. (Admittedly, Microsoft ships its own opcode cache for PHP.) iamstever -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
