Hi,
Am 06.02.2014 00:57, schrieb Xueming Shen:
On 02/05/2014 03:28 PM, Ulf Zibis wrote:
Additionally you could use Character.isSurrogate() and Character.isSupplementaryCode<point() at
appropriate places. Both are better optimized for JIT.
j.l.C.isSupplementaryCodePoint() checks up boundary of supp, we probably don't
need it
here, as the returning code point is either a ERROR or a valid unicode code
point.
Sorry, I was in error. I meant using !isBmpCodePoint() which is
codePoint >>> 16 != 0
which is should be slightly faster than
codePoint >= Character.MIN_SUPPLEMENTARY_CODE_POINT
as the latter needs a 32-bit value to be loaded.
I'm not sure about the j.l.C.isSurrogate(), which takes a char and we have an
int here.
I would expect the javac will inline the constants for me, but I don't know
whether jit
can inline and then optimize away the explicit casting i2c. Not a big deal
though.
Why you use (in) here, you could do the cast later?
Yes, IIRC from my HSdis inspection, i2c is a Noop and yes, isSurrogate() is
better to read.
Additionally I remember, we had discussion if isSurrogate() would be faster with
(byte)(ch >>> 11) == (byte)(0xD8 >>> 3)
So if isSurrogate() will be optimised in future or even intrinsified, using isSurrogate() should be
better than
ch >= MIN_HIGH_SURROGATE&& c <= MAX_HIGH_SURROGATE
Please note:
ch >= MIN_SURROGATE && ch < (MAX_SURROGATE + 1)
generally is better than:
ch >= MIN_HIGH_SURROGATE&& c <= MAX_HIGH_SURROGATE
See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6984886
-Ulf
