Tim Starling wrote: > That's not the world I live in. I work on a pure-PHP application which > is widely used on servers where the installing user does not have the > ability to change their php.ini or to install extensions or middleware. > The same application (with a few small extensions in C/C++) is used to > run one of the largest destinations on the Web. It all works just fine, > and you sell PHP short when you imply that it can't do this. We're not > going to fork MediaWiki just because you think it can't be done: it can > be done and we're doing it.
But aren't the people who have large installs also likely to be running on something slightly beyond an $10/month shared hosting account? I bet a mediawiki extension would be quite popular with the dedicated server users along with all the slicehost/linode folks who splurge and pay $40/month for their hosting. > The original poster suggested an optimisation pass post-compile, which > obviously doesn't break anything because there's extensions that do it > already. So I don't know who you're arguing against. I'm not arguing against anything, simply explaining how we got here. I am all for optimizations that don't break everything. In the case of a post-compile optimization pass nobody has been able to write one that could speed up normal code without caching the optimized opcodes. We do have pecl/optimizer which works in conjunction with APC. It can easily be made to work without APC, but there isn't much point since the pass always takes longer than the execution time it can save unless the code being optimized is absolutely horrendous. We have also played with some of your other ideas in the past, but I suppose most of the core devs are somewhat spoiled by not needing to run an entire Wikipedia clone on a $10 shared hosting account. All I can say on this is, send some patches to the list. PHP improves through code. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
