Sherman,
I know, your time ...
... but maybe someone is needed for sponsor here:
https://bugs.openjdk.java.net/show_bug.cgi?id=100132
Could you do this?
Much thanks,
-Ulf
Am 10.03.2010 19:23, schrieb Xueming Shen:
approved.
I don't have a spare ws right now.so please just push, it's almost
there:-)
sherman
Martin Buchholz wrote:
Here's the proposed fix for
6931812: A better implementation of sun.nio.cs.Surrogate.isBMP(int)
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/isBMPCodePoint/
I changed the name to isBMPCodePoint in preparation for moving
it to Character.java.
(Sherman, perhaps you would like to take on that followon task?)
Sherman, please approve.
Martin
On Sat, Mar 6, 2010 at 13:00, Ulf Zibis <ulf.zi...@gmx.de> wrote:
Very fast Sherman, much thanks.
Could you set the bug to accepted and evaluated, so my patch will
have a
chance to get into the code base?
-Ulf
Am 03.03.2010 20:11, schrieb Xueming Shen:
#6931812
Martin Buchholz wrote:
Sherman, would you like to file bugs for Ulf's improvements?
On Wed, Mar 3, 2010 at 02:44, Ulf Zibis <ulf.zi...@gmx.de> wrote:
Am 03.03.2010 09:00, schrieb Martin Buchholz:
Keep in mind that supplementary characters are extremely rare.
Yes, but many API's in the JDK are used rarely.
Why should they waste memory footprint / perform bad,
particularly if it
doesn't cost anything.
I admire your perfectionism.
Therefore the existing implementation
return codePoint>= MIN_SUPPLEMENTARY_CODE_POINT
&& codePoint<= MAX_CODE_POINT;
will almost always perform just one comparison against a constant,
which is hard to beat.
1. Wondering: I think there are TWO comparisons.
2. Those comparisons need to load 32 bit values from machine code,
against
only 8 bit values in my case.
It's a good point. In the machine code, shifts are likely to use
immediate values, and so will be a small win.
int x = codePoint >>> 16;
return x != 0 && x < 0x11;
(On modern hardware, these optimizations
are less valuable than they used to be;
ordinary integer arithmetic is almost free)
Martin
