Fair enough. I don't think it's going to be a measurable difference. I
have updated the webrev
to use the Character.isSurrogate() for better readability.
http://cr.openjdk.java.net/~sherman/8032012/webrev
-Sherman
On 2/5/14 6:21 PM, Vitaly Davidovich wrote:
i2c conversion should not cost anything; it'll just make jit use low
16 bits of the registers for (unsigned) comparisons. I haven't
checked this though, but that's what I'd expect.
Sent from my phone
On Feb 5, 2014 7:27 PM, "Xueming Shen" <[email protected]
<mailto:[email protected]>> wrote:
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.
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.
-sherman
-Ulf
Am 05.02.2014 22:30, schrieb Xueming Shen:
Hi Remi,
Good suggestion. Now the "common case" path is much simple
and faster :-)
I'm seeing a 5%-10% boost for the normal-non-surrogates
case. And it appears
the bmp+surr mixed is getting faster as well. Though I
would assume the it
would get slower in case of "no-case-folding" +
surrogates. But the common
case wins here.
http://cr.openjdk.java.net/~sherman/8032012/webrev/
<http://cr.openjdk.java.net/%7Esherman/8032012/webrev/>
