Well, if you want my 2 cents as well, the 2 cents a PHP user is very willing to share with you guys...
PHP6 is a major release. BC is a priority, but as far as I'm concerned not the top priority. I wouldn't mind a unicode-only PHP at all. Like a few others here, I think the speed penalty won't be huge at all. It's not like my scripts are 90% string handling (and I assume the unicode benchmark scripts are). I wouldn't want you guys having a messy codebase just because you want to support non-unicode and unicode. I also wouldn't want you guys branching to a non-unicode line of PHP releases. It would just be too much. As far as I'm concerned, I'd be fine with a unicode only PHP6. Unicode is progress. I think a lot of the people who don't want it, don't yet see the positive things it brings. Ron "Peter Brodersen" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] On Sun, 9 Oct 2005 00:55:45 -0400 (EDT), in php.internals [EMAIL PROTECTED] (Adam Maccabee Trachtenberg) wrote: >We seem to be under the impression that the Unicode speed penalty will >be so harsh that a Unicode-only PHP 6 will be too slow for >use. However, we don't know that for sure. Yes, it will be slower, >when you look at the whole request cycle, it may not matter. I agree - the speed penalty comparsion seems mostly related to php scripts that does nothing else than handling strings. I recall the old discussions (echo vs print vs ?>...<? ) using similar benchmarks. It is true when you compare the specific functions/language constructs the relative difference in speed is apparent. But compared to a bunch of other functions that you'll usually use (database connections, file access, data sorting, etc.) I imagine that the speed penalty is simply marginal. Just my 0.02 \x20B1. -- - Peter Brodersen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
