RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v2]
XenoAmess
duke at openjdk.java.net
Wed Apr 20 21:08:19 UTC 2022
On Wed, 20 Apr 2022 20:56:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>>
>> add jmh test
>
> Thanks for the JMH tests and data.
>
> The only part needed from the JMH run is the last 9 lines. The rest is noise.
> If it was formatted as a literal it would be easier to read.
>
> What I see is that the run with == is quite a bit slower.
>
> With the == check:
>
>
> StringOther.regionMatchesU1024LL avgt 15 187.258 ± 1.038 ns/op
> StringOther.regionMatchesU1024LU avgt 15 2589.833 ± 8.823 ns/op
> StringOther.regionMatchesU1024UL avgt 15 2379.645 ± 6.481 ns/op
> StringOther.regionMatchesU1024UU avgt 15 191.587 ± 7.069 ns/op
>
>
> Without the == check:
>
>
> StringOther.regionMatchesU1024LL avgt 15 187.732 ± 1.914 ns/op
> StringOther.regionMatchesU1024LU avgt 15 1324.156 ± 11.761 ns/op
> StringOther.regionMatchesU1024UL avgt 15 1331.857 ± 22.509 ns/op
> StringOther.regionMatchesU1024UU avgt 15 188.872 ± 2.396 ns/op
>
>
> In the JMH cases, does the long prefix of latin1 characters distort the timings?
@RogerRiggs
> What I see is that the run with == is quite a bit slower.
Yes, the result is amazing to me. Before you reply I re-run several times but similar result. So I respect the truth.
> In the JMH cases, does the long prefix of latin1 characters distort the timings?
No, the long prefix part is where real difference comes.
So according to jmh result, the = check removed.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8308
More information about the core-libs-dev
mailing list