Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Unicode Implementation »

Unicode Implementation

php.internals

Derick Rethans

20 years ago
Hello! I am thinking that we're doing something with the unicode implementation and that's that we're now getting duplicate implementations of quite some things: functions, internal functions, hash implementations, two ways for storing identifiers... only because we need to support both IS_STRING and IS_UNICODE and unicode=off mode. I think I would prefer an IS_UNICODE/unicode=on only PHP. This would mean that: - no duplicate functionality for tons of functions that will make maintaining the thing very hard - a cleaner (and a bit faster) Unicode implementation - we have a bit less BC. Internally we would only see IS_UNICODE and IS_BINARY, where we can have a small layer around extensions which return IS_STRING where we automatically convert it to and from unicode for those extensions. IS_STRING strings will still exist, but should not be there for the "user level". For things like: $str = unicode_convert($unicode, 'iso-2022'); and $unicode being "IS_UNICODE". $str will now be an IS_BINARY string, with all the restrictions that we already have on those strings (like no automatic conversions). Functions that work on binary strings can be quite limited (we wouldn't need a strtolower for that f.e.), so we are cutting down in a lot of duplicated code. The same goes for not having to support both unicode=off and unicode=on mode, as that can make things a bit complicated too. This will limit functionality on binary strings a bit though, but I think this is 10 times better than an unmaintainable PHP with Unicode support. Besides this, I ran some micro benchmarks on about 600 characters of text with a few functions and benchmarked their behavior between unicode=1 and unicode=0 mode. Results: strrev (100.000 iterations over 600 characters of normalized latin text): unicode off: 1.8secs unicode on: 5.0secs strtoupper (100.000 iterations over the same text): unicode off: 2.2secs unicode on: 7.9secs substr(50, 100) (1.000.000 over the same text): unicode off: 3.9secs unicode on: 11.9secs This is something I find quite not acceptable, and we need to figure out a way on how to optimize this - for substr the penalty is probably what we are using an iterator and not a direct memcpy (because of surrogates), I am not so sure about the others. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Marcus Börger

20 years ago
Hello Derick, Thursday, October 6, 2005, 7:56:34 PM, you wrote:
> Hello!
> I am thinking that we're doing something with the unicode implementation and > that's that we're now getting duplicate implementations of quite some things: > functions, internal functions, hash implementations, two ways for storing > identifiers... only because we need to support both IS_STRING and IS_UNICODE > and unicode=off mode.
> I think I would prefer an IS_UNICODE/unicode=on only PHP.
+infinity (...) Best regards, Marcus

Andrei Zmievski

20 years ago
On Oct 6, 2005, at 10:56 AM, Derick Rethans wrote:
> I am thinking that we're doing something with the unicode > implementation and > that's that we're now getting duplicate implementations of quite some > things: > functions, internal functions, hash implementations, two ways for > storing > identifiers... only because we need to support both IS_STRING and > IS_UNICODE > and unicode=off mode. > > I think I would prefer an IS_UNICODE/unicode=on only PHP. > > This would mean that: > - no duplicate functionality for tons of functions that will make > maintaining > the thing very hard
This is true.
> - a cleaner (and a bit faster) Unicode implementation
This is true too.
> - we have a bit less BC.
"A bit less"? I'd say it would break BC in a major way. People who want to upgrade to PHP 6 would need to rewrite a lot of their scripts.
> Internally we would only see IS_UNICODE and IS_BINARY, where we can > have a > small layer around extensions which return IS_STRING where we > automatically > convert it to and from unicode for those extensions. IS_STRING strings > will > still exist, but should not be there for the "user level". > > For things like: > $str = unicode_convert($unicode, 'iso-2022'); > and $unicode being "IS_UNICODE". $str will now be an IS_BINARY string, > with all > the restrictions that we already have on those strings (like no > automatic > conversions). > > Functions that work on binary strings can be quite limited (we > wouldn't need a > strtolower for that f.e.), so we are cutting down in a lot of > duplicated code. > The same goes for not having to support both unicode=off and > unicode=on mode, > as that can make things a bit complicated too. This will limit > functionality on > binary strings a bit though, but I think this is 10 times better than > an > unmaintainable PHP with Unicode support.
Sure, if you remove requirement for BC and merge the string/binary semantics, you can use IS_BINARY for all that stuff.
> Besides this, I ran some micro benchmarks on about 600 characters of > text with > a few functions and benchmarked their behavior between unicode=1 and > unicode=0 > mode. Results: > > strrev (100.000 iterations over 600 characters of normalized latin > text): > unicode off: 1.8secs > unicode on: 5.0secs > > strtoupper (100.000 iterations over the same text): > unicode off: 2.2secs > unicode on: 7.9secs > > substr(50, 100) (1.000.000 over the same text): > unicode off: 3.9secs > unicode on: 11.9secs > > This is something I find quite not acceptable, and we need to figure > out a way > on how to optimize this - for substr the penalty is probably what we > are using > an iterator and not a direct memcpy (because of surrogates), I am not > so sure > about the others.
We can try switching to _UNSAFE versions of the iterator macros - they assume well-formed UTF-16, so they will be somewhat faster. -Andrei

Derick Rethans

20 years ago
On Thu, 6 Oct 2005, Andrei Zmievski wrote:
> On Oct 6, 2005, at 10:56 AM, Derick Rethans wrote: > > > > I think I would prefer an IS_UNICODE/unicode=on only PHP. > > > > This would mean that: > > - no duplicate functionality for tons of functions that will make > > maintaining the thing very hard > > This is true. > > > - a cleaner (and a bit faster) Unicode implementation > > This is true too. > > > - we have a bit less BC. > > "A bit less"? I'd say it would break BC in a major way. People who want to > upgrade to PHP 6 would need to rewrite a lot of their scripts.
Can you please specify which things you think that will break? I've gave it some thoughts but couldn't really think of anything serious...
> > This is something I find quite not acceptable, and we need to figure > > out a way on how to optimize this - for substr the penalty is > > probably what we are using an iterator and not a direct memcpy > > (because of surrogates), I am not so sure about the others. > > We can try switching to _UNSAFE versions of the iterator macros - they > assume well-formed UTF-16, so they will be somewhat faster.
That's worth a try - I'll put that on my todo list somewhere. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Ilia A.

20 years ago
Andrei Zmievski wrote:
>> - we have a bit less BC. > > > "A bit less"? I'd say it would break BC in a major way. People who want > to upgrade to PHP 6 would need to rewrite a lot of their scripts.
I think most large applications will be in this boat anyway, we may as well do it properly once, so we don't end up hacks on top of hacks just for the sake of BC.
> We can try switching to _UNSAFE versions of the iterator macros - they > assume well-formed UTF-16, so they will be somewhat faster.
We definitely need to look at that since if upgrading to 6.0 means a 3x slower operation very few people will even consider upgrading. Ilia

Rasmus Lerdorf

20 years ago
Ilia Alshanetsky wrote:
> Andrei Zmievski wrote: > >>>- we have a bit less BC. >> >> >>"A bit less"? I'd say it would break BC in a major way. People who want >>to upgrade to PHP 6 would need to rewrite a lot of their scripts. > > > I think most large applications will be in this boat anyway, we may as > well do it properly once, so we don't end up hacks on top of hacks just > for the sake of BC. > > >>We can try switching to _UNSAFE versions of the iterator macros - they >>assume well-formed UTF-16, so they will be somewhat faster. > > > We definitely need to look at that since if upgrading to 6.0 means a 3x > slower operation very few people will even consider upgrading.
Which is why we need the unicode=off switch. I don't think there is any way we can make Unicode PHP as fast as non-Unicode PHP. For people who need Unicode support, Unicode PHP will be faster and easier than any other way for them to get there, but for people who have no need for Unicode it would be really nice to maintain the fast non-Unicode mode. -Rasmus

Derick Rethans

20 years ago
On Fri, 7 Oct 2005, Rasmus Lerdorf wrote:
> > We definitely need to look at that since if upgrading to 6.0 means a 3x > > slower operation very few people will even consider upgrading. > > Which is why we need the unicode=off switch. I don't think there is any > way we can make Unicode PHP as fast as non-Unicode PHP. For people who > need Unicode support, Unicode PHP will be faster and easier than any > other way for them to get there, but for people who have no need for > Unicode it would be really nice to maintain the fast non-Unicode mode.
What is wrong with PHP 5.1? People don't *have* to upgrade to the unicode enabled PHP if they don't want to. And it would probably be "nice" to have that mode for some users, but should that be over our own back with multiple implementations of everything? regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Rasmus Lerdorf

20 years ago
Derick Rethans wrote:
> On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: > > >>>We definitely need to look at that since if upgrading to 6.0 means a 3x >>>slower operation very few people will even consider upgrading. >> >>Which is why we need the unicode=off switch. I don't think there is any >>way we can make Unicode PHP as fast as non-Unicode PHP. For people who >>need Unicode support, Unicode PHP will be faster and easier than any >>other way for them to get there, but for people who have no need for >>Unicode it would be really nice to maintain the fast non-Unicode mode. > > > What is wrong with PHP 5.1? People don't *have* to upgrade to the > unicode enabled PHP if they don't want to. And it would probably be > "nice" to have that mode for some users, but should that be over our own > back with multiple implementations of everything?
The "don't upgrade" argument doesn't work. Unless we commit to having two major versions forever where we will add new features. That is a possibility as well of course. Have 2 trees. Unicode-PHP and non-Unicode-PHP and everything that is not Unicode-related will need to be committed to both. -Rasmus

Derick Rethans

20 years ago
On Fri, 7 Oct 2005, Rasmus Lerdorf wrote:
> > What is wrong with PHP 5.1? People don't *have* to upgrade to the > > unicode enabled PHP if they don't want to. And it would probably be > > "nice" to have that mode for some users, but should that be over our own > > back with multiple implementations of everything? > > The "don't upgrade" argument doesn't work. Unless we commit to having > two major versions forever where we will add new features. That is a > possibility as well of course. Have 2 trees. Unicode-PHP and > non-Unicode-PHP and everything that is not Unicode-related will need to > be committed to both.
yeah, and if that allows us to cleanup PHP 6 for real, then I am not even sure if that is such a bad solution. Ofcourse, the new cool features would go to PHP 6 only, but that's now the same wih 4.4 and 5.1 too anyway. But I don't want to jump too quickly to conclusions about the UNicode speed and BC breakage. All I tested is raw string functions and there is no way that the whole application slows down as much as we saw in the few benchmarks that I run. Besides that, we can probably optimize the string functions somewhat anyway. I'd like to see the speed decrease for real applications too. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

John Coggeshall

20 years ago
On Fri, 2005-10-07 at 22:09 +0100, Rasmus Lerdorf wrote:
> The "don't upgrade" argument doesn't work. Unless we commit to having > two major versions forever where we will add new features. That is a > possibility as well of course. Have 2 trees. Unicode-PHP and > non-Unicode-PHP and everything that is not Unicode-related will need to > be committed to both.
I think this would lead to PHP 6.2 with two different sets of functionality (Joe writes some super-string-manipulating thing for PHP 6.2, never find the time to port it to 6.2-unicode, and now no one else has time to do it either so we release one with the function, one without yet they are both 6.2). While I understand the argument that PHP itself will be slower with Unicode support, and there isn't much we can do about that (we're just doing a heck of a lot more work across the board), I think the best option is to have PHP 6 be completely Unicode. It will break applications, but they can be ported. It will mean PHP is going to be slower, but other languages have found ways to make up for that speed decrease in other places and I am sure we could learn from looking at them for answers to our problem. Cheers, John

Marcus Börger

20 years ago
Hello John, Friday, October 7, 2005, 11:47:14 PM, you wrote:
> On Fri, 2005-10-07 at 22:09 +0100, Rasmus Lerdorf wrote: >> The "don't upgrade" argument doesn't work. Unless we commit to having >> two major versions forever where we will add new features. That is a >> possibility as well of course. Have 2 trees. Unicode-PHP and >> non-Unicode-PHP and everything that is not Unicode-related will need to >> be committed to both.
> I think this would lead to PHP 6.2 with two different sets of > functionality (Joe writes some super-string-manipulating thing for PHP > 6.2, never find the time to port it to 6.2-unicode, and now no one else > has time to do it either so we release one with the function, one > without yet they are both 6.2).
> While I understand the argument that PHP itself will be slower with > Unicode support, and there isn't much we can do about that (we're just > doing a heck of a lot more work across the board), I think the best > option is to have PHP 6 be completely Unicode. It will break > applications, but they can be ported. It will mean PHP is going to be > slower, but other languages have found ways to make up for that speed > decrease in other places and I am sure we could learn from looking at > them for answers to our problem.
For instance PHP 6 could undergo a design face for some clearing which should imho includecase-sensitivity every where and ups, why is PHP 6 suddenly faster? We could also add a mode that disalloas dynamic class rewriting which is very clever once we have the build in apc or which ever bytecode compiler we chosse and ups! no it is even much faster when using objects. But to me the best thing would be to finally haver a plan. A real plan we stick to. And then outline how long we plan to support 5.x series. Because if we do so we can finally take us some time and change a few things in 6. But maybe some companies like it more to get 6 out asap and have little BC issues every now and then. Those companies with their private code - they don't have a real problem with that. It is the majority of small sites. People that want new features every now and then. And then it is a problem because the majotity of servers come with exactly one PHP version installed. Perhaps it is a good idea to suggest to have PHP 4.*, PHP 5.* and PHP 6.* installed in parallel. Because only if we suggest so that might happen. And if it happens there is no such thing as BC. But well is any body still reading or caring for what i write? Best regards, Marcus

George Schlossnagle

20 years ago
On Oct 7, 2005, at 5:05 PM, Derick Rethans wrote:
> On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: >> >> Which is why we need the unicode=off switch. I don't think there >> is any >> way we can make Unicode PHP as fast as non-Unicode PHP. For >> people who >> need Unicode support, Unicode PHP will be faster and easier than any >> other way for them to get there, but for people who have no need for >> Unicode it would be really nice to maintain the fast non-Unicode >> mode. >> > > What is wrong with PHP 5.1? People don't *have* to upgrade to the > unicode enabled PHP if they don't want to. And it would probably be > "nice" to have that mode for some users, but should that be over > our own > back with multiple implementations of everything?
Are you suggesting that people who don't want unicode should stick with 5.1 for perpetuity? George

Ilia A.

20 years ago
George Schlossnagle wrote:
>> What is wrong with PHP 5.1? People don't *have* to upgrade to the >> unicode enabled PHP if they don't want to. And it would probably be >> "nice" to have that mode for some users, but should that be over our own >> back with multiple implementations of everything? > > > Are you suggesting that people who don't want unicode should stick with > 5.1 for perpetuity?
Assuming that 5.1 would be actively maintained and not just for bug fixes, I'd say that is a viable approach. There are plenty of sites that have no use for Unicode as nice as it may be, and much rather retain performance over useless (for them) functionality. Ilia

Rasmus Lerdorf

20 years ago
Ilia Alshanetsky wrote:
> George Schlossnagle wrote: > >>>What is wrong with PHP 5.1? People don't *have* to upgrade to the >>>unicode enabled PHP if they don't want to. And it would probably be >>>"nice" to have that mode for some users, but should that be over our own >>>back with multiple implementations of everything? >> >> >>Are you suggesting that people who don't want unicode should stick with >>5.1 for perpetuity? > > > Assuming that 5.1 would be actively maintained and not just for bug > fixes, I'd say that is a viable approach. There are plenty of sites that > have no use for Unicode as nice as it may be, and much rather retain > performance over useless (for them) functionality.
So, you are saying that something like the namespace patch would be added between 5.1.2 and 5.1.3, for example? That doesn't make much sense to me. -Rasmus

Derick Rethans

20 years ago
On Fri, 7 Oct 2005, Rasmus Lerdorf wrote:
> > Assuming that 5.1 would be actively maintained and not just for bug > > fixes, I'd say that is a viable approach. There are plenty of sites that > > have no use for Unicode as nice as it may be, and much rather retain > > performance over useless (for them) functionality. > > So, you are saying that something like the namespace patch would be > added between 5.1.2 and 5.1.3, for example? That doesn't make much > sense to me.
True, but doing it between 5.1.1 and 5.2.0 would work. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Rasmus Lerdorf

20 years ago
Derick Rethans wrote:
> On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: > > >>>Assuming that 5.1 would be actively maintained and not just for bug >>>fixes, I'd say that is a viable approach. There are plenty of sites that >>> have no use for Unicode as nice as it may be, and much rather retain >>>performance over useless (for them) functionality. >> >>So, you are saying that something like the namespace patch would be >>added between 5.1.2 and 5.1.3, for example? That doesn't make much >>sense to me. > > > True, but doing it between 5.1.1 and 5.2.0 would work.
Right, so effectively the 5.x and 6.x trees would mimic each other. Even major versions = unicode, odd version = non-unicode. I suppose it is an approach, but I think it is a confusing one. -Rasmus

George Schlossnagle

20 years ago
On Oct 7, 2005, at 5:41 PM, Rasmus Lerdorf wrote:
> Ilia Alshanetsky wrote: > >> George Schlossnagle wrote: >> >> >>>> What is wrong with PHP 5.1? People don't *have* to upgrade to the >>>> unicode enabled PHP if they don't want to. And it would probably be >>>> "nice" to have that mode for some users, but should that be >>>> over our own >>>> back with multiple implementations of everything? >>>> >>> >>> >>> Are you suggesting that people who don't want unicode should >>> stick with >>> 5.1 for perpetuity? >>> >> >> >> Assuming that 5.1 would be actively maintained and not just for bug >> fixes, I'd say that is a viable approach. There are plenty of >> sites that >> have no use for Unicode as nice as it may be, and much rather retain >> performance over useless (for them) functionality. >> > > So, you are saying that something like the namespace patch would be > added between 5.1.2 and 5.1.3, for example? That doesn't make much > sense to me.
Perhaps we need a separate version fork for the unicode support. I'm thinking one of those nifty unicode glyphs. It could be called 'the language formerly known as PHP'. George

Rasmus Lerdorf

20 years ago
George Schlossnagle wrote:
> Perhaps we need a separate version fork for the unicode support. I'm > thinking one of those nifty unicode glyphs. It could be called 'the > language formerly known as PHP'.
The Phillipine currency is called PHP. Do they perhaps have a currency symbol? -Rasmus

Ilia A.

20 years ago
Rasmus Lerdorf wrote:
>>Assuming that 5.1 would be actively maintained and not just for bug >>fixes, I'd say that is a viable approach. There are plenty of sites that >> have no use for Unicode as nice as it may be, and much rather retain >>performance over useless (for them) functionality. > > > So, you are saying that something like the namespace patch would be > added between 5.1.2 and 5.1.3, for example? That doesn't make much > sense to me.
No, we bug fix in 5.1.X and put big features into 5.2, in 5.2.X work on fixing bugs and when we have enough, move to 5.3 and repeat... Ilia

Jani Taskinen

20 years ago
On Fri, 7 Oct 2005, Ilia Alshanetsky wrote:
> > George Schlossnagle wrote: >>> What is wrong with PHP 5.1? People don't *have* to upgrade to the >>> unicode enabled PHP if they don't want to. And it would probably be >>> "nice" to have that mode for some users, but should that be over our own >>> back with multiple implementations of everything? >> >> >> Are you suggesting that people who don't want unicode should stick with >> 5.1 for perpetuity? > > Assuming that 5.1 would be actively maintained and not just for bug > fixes, I'd say that is a viable approach. There are plenty of sites that > have no use for Unicode as nice as it may be, and much rather retain > performance over useless (for them) functionality.
5.1, 5.2, 5.3..where was it said that 5.1 has to stop at 5.1 ? :) --Jani

Adam Maccabee Trachtenberg

20 years ago
On Fri, 7 Oct 2005, Derick Rethans wrote:
> On Fri, 7 Oct 2005, Rasmus Lerdorf wrote: > > > Which is why we need the unicode=off switch. I don't think there is any > > way we can make Unicode PHP as fast as non-Unicode PHP. For people who > > need Unicode support, Unicode PHP will be faster and easier than any > > other way for them to get there, but for people who have no need for > > Unicode it would be really nice to maintain the fast non-Unicode mode. > > What is wrong with PHP 5.1? People don't *have* to upgrade to the > unicode enabled PHP if they don't want to. And it would probably be > "nice" to have that mode for some users, but should that be over our own > back with multiple implementations of everything?
I got to agree with Derick. I certainly understand that speed is important, but people somehow manage to develop Web sites in Java, C#, and Perl, and all those languages are Unicode only. 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. Therefore, all the extra work we're doing today seems to be premature optimization (a.k.a. "the root of all evil") that only adds to code complexity and delays PHP 6. We'd be better off building PHP 6 as Unicode-only and spending the extra time that we're currently using on the non-Unicode mode tuning PHP 6 the best we can. If we somehow fail to get it fast enough for a certain subset of users, and those users cannot afford to buy better machines, then and only then should we figure out how solve the problem of making PHP 6 support a non-Unicode mode. -adam
-- adam@trachtenberg.com | http://www.trachtenberg.com author of o'reilly's "upgrading to php 5" and "php cookbook" avoid the holiday rush, buy your copies today!

Peter Brodersen

20 years ago
On Sun, 9 Oct 2005 00:55:45 -0400 (EDT), in php.internals adam@trachtenberg.com (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

Ron Korving

20 years ago
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" <php@ter.dk> schreef in bericht news:s7hkk1l00v0gerlccnsc0937ov977j5og4@4ax.com... On Sun, 9 Oct 2005 00:55:45 -0400 (EDT), in php.internals adam@trachtenberg.com (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

Jevon Wright

20 years ago
Ditto please! Jevon ----- Original Message ----- From: "Ron Korving" <r.korving@xit.nl> To: <internals@lists.php.net> Sent: Thursday, October 13, 2005 8:27 PM Subject: [php] Re: [PHP-DEV] Unicode Implementation
> 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.

Oliver Grätz

20 years ago
And remember: PHP6 will not be released for at least a year. So by then typical servers will run at several hundred MHz more, so perhaps the speed penalty won't be noticed at all. This is even more true compared to the current speed of PHP as there will (If I recall this correctly) be significant performance enhancements of the Zend Engine with the switch from 5.0 to 5.1. OLLi ____________ "No self-respecting man in Iowa goes anywhere without beer." [LOST 122]

Ilia A.

20 years ago
Oliver Grätz wrote:
> And remember: PHP6 will not be released for at least a year. So by then > typical servers will run at several hundred MHz more, so perhaps the > speed penalty won't be noticed at all.
And people will do more with PHP ultimately making the MHz boost irrelevant. Despite tremendous increases in hardware performance, the software we run seems to run slower and slower.
> This is even more true compared > to the current speed of PHP as there will (If I recall this correctly) > be significant performance enhancements of the Zend Engine with the > switch from 5.0 to 5.1.
PHP 5.0 is MUCH slower the PHP 5.1, all PHP 5.1 does is bring the performance back on part with 4.X in most cases (not all, even) when used in conjunction with an opcode code cache such as APC. Ilia

Oliver Grätz

20 years ago
Ilia Alshanetsky schrieb:
>>And remember: PHP6 will not be released for at least a year. So by then >>typical servers will run at several hundred MHz more, so perhaps the >>speed penalty won't be noticed at all. > And people will do more with PHP ultimately making the MHz boost > irrelevant. Despite tremendous increases in hardware performance, the > software we run seems to run slower and slower.
Which doesn't stop them from moving from PHP to Ruby (which I suppose is slower than PHP will ever be). I know that more power is always eaten by more complex software but this is not valid for ordinary applications.
>>This is even more true compared >>to the current speed of PHP as there will (If I recall this correctly) >>be significant performance enhancements of the Zend Engine with the >>switch from 5.0 to 5.1. > > PHP 5.0 is MUCH slower the PHP 5.1, all PHP 5.1 does is bring the > performance back on part with 4.X in most cases (not all, even) when > used in conjunction with an opcode code cache such as APC.
The microbenchmarks on http://www.ister.org/code/article/de/php45bench.xhtml indicate that PHP5 is slower than PHP4, but in the note at the end there is some evidence that PHP5.1 will be significantly faster than PHP4 when it comes to objects and classes (which is what people who "do more with PHP" will be using). AllOLLi ____________ Backup? Backup? ...I knew I forgot something!

Ilia A.

20 years ago
Oliver Grätz wrote:
> http://www.ister.org/code/article/de/php45bench.xhtml > > indicate that PHP5 is slower than PHP4, but in the note at the end there > is some evidence that PHP5.1 will be significantly faster than PHP4 when > it comes to objects and classes (which is what people who "do more with > PHP" will be using).
Tests conducted using real PHP applications such as Gallery,FUDforum,phpMyAdmin show different results. Ilia

Jani Taskinen

20 years ago
On Thu, 13 Oct 2005, Oliver Grätz wrote:
>> And people will do more with PHP ultimately making the MHz boost >> irrelevant. Despite tremendous increases in hardware performance, the >> software we run seems to run slower and slower. > > Which doesn't stop them from moving from PHP to Ruby (which I suppose is > slower than PHP will ever be).
And that they're perfectly free to do. I even encourage them to do so if it provides what they need now instead of waiting what we'll break next. --Jani

Pierre Joye

20 years ago
On Thu, 13 Oct 2005 17:43:03 +0200 oliver.graetz@arcor.de (Oliver Grätz) wrote:
> And remember: PHP6 will not be released for at least a year. So by > then typical servers will run at several hundred MHz more, so perhaps > the speed penalty won't be noticed at all.
This argument is irrelevant. You only hide the possible lack of scalability behind hardware improvements. --Pierre

Oliver Grätz

20 years ago
Pierre schrieb:
> This argument is irrelevant. You only hide the possible lack of > scalability behind hardware improvements.
A "lack of scalability" will only occur if the Unicode features create a more than linear performance drop which I suppose won't happen. Even if it becomes three times slower this is NO problem to think about when deciding for or against a side-by-side unicode/non-unicode environment since this is very well "scalable". AllOLLi ____________ According to my calculations the problem doesn't exist.

Pierre Joye

20 years ago
On Thu, 13 Oct 2005 21:02:09 +0200 oliver.graetz@arcor.de (Oliver Grätz) wrote:
> Pierre schrieb: > > > This argument is irrelevant. You only hide the possible lack of > > scalability behind hardware improvements. > > A "lack of scalability" will only occur if the Unicode features > create a more than linear performance drop which I suppose won't > happen. Even if it becomes three times slower this is NO problem to > think about when deciding for or against a side-by-side > unicode/non-unicode environment since this is very well "scalable".
You miss my point. Saying that in one year hardware will run a few Mhz faster is plain stupid. You only delay the point of failure. --Pierre