RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement
Xueming Shen
xueming.shen at oracle.com
Thu Feb 6 04:37:35 UTC 2014
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" <xueming.shen at oracle.com
> <mailto:xueming.shen at oracle.com>> 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/>
>
>
>
More information about the core-libs-dev
mailing list