[PATCH] unnecessary null check inside of java.lang.Boolean.valueOf(String)

[Martin Buchholz]

Сергей: Thanks for the benchmarking.
I would always do benchmarking with latest available jdk, i.e. jdk11.
You don't say which variant is better and which is best!
But the difference is small enough we should go with the simpler one you
originally suggested

return "true".equalsIgnoreCase(s);

I suspect hotspot uses the fact that the receiver is a constant.

On Thu, Mar 22, 2018 at 1:02 PM, Сергей Цыпанов <sergei.tsypanov at yandex.ru>
wrote:

> I've measured performance of suggested code comparing with previous
> variants (5 forks, 5 warmup and 10 measurement iterations, 1 s each).
> Here's the output for JDK 9.0.4:
>
> Benchmark                                (str)  Mode  Cnt  Score   Error
> Thanks for the benchmarking.
> I would always do benchmarking with latest available jdk, i.e. jdk11.
> You don't say which variant is better and which is best!
> But the difference is small enough we should go with the simpler one you
> originally suggested
>
> eturn "true".equalsIgnoreCase(s);
>
> On Thu, Mar 22, 2018 at 1:02 PM, Сергей Цыпанов <sergei.tsypanov at yandex.ru>
> wrote:
> I've measured performance of suggested code comparing with previous
> variants (5 forks, 5 warmup and 10 measurement iterations, 1 s each).
> Here's the output for JDK 9.0.4:
>
> Benchmark                                (str)  Mode  Cnt  Score   Error
> Units
> EqualsIgnoreCaseBenchmark.bestMethod      true  avgt   50  5,552 ± 0,070
> ns/op
> EqualsIgnoreCaseBenchmark.bestMethod     false  avgt   50  2,703 ± 0,054
> ns/op
> EqualsIgnoreCaseBenchmark.bestMethod      null  avgt   50  2,248 ± 0,076
> ns/op
>
> EqualsIgnoreCaseBenchmark.betterMethod    true  avgt   50  5,072 ± 0,626
> ns/op
> EqualsIgnoreCaseBenchmark.betterMethod   false  avgt   50  2,955 ± 0,072
> ns/op
> EqualsIgnoreCaseBenchmark.betterMethod    null  avgt   50  2,416 ± 0,040
> ns/op
>
> EqualsIgnoreCaseBenchmark.defaultMethod   true  avgt   50  8,986 ± 0,159
> ns/op
> EqualsIgnoreCaseBenchmark.defaultMethod  false  avgt   50  2,912 ± 0,162
> ns/op
> EqualsIgnoreCaseBenchmark.defaultMethod   null  avgt   50  2,186 ± 0,027
> ns/op
>
> and for JDK 10
>
> Benchmark                                (str)  Mode  Cnt  Score   Error
> Units
> EqualsIgnoreCaseBenchmark.bestMethod      true  avgt   50  5,672 ± 0,071
> ns/op
> EqualsIgnoreCaseBenchmark.bestMethod     false  avgt   50  3,120 ± 0,040
> ns/op
> EqualsIgnoreCaseBenchmark.bestMethod      null  avgt   50  2,705 ± 0,060
> ns/op
>
> EqualsIgnoreCaseBenchmark.betterMethod    true  avgt   50  5,141 ± 0,080
> ns/op
> EqualsIgnoreCaseBenchmark.betterMethod   false  avgt   50  3,436 ± 0,049
> ns/op
> EqualsIgnoreCaseBenchmark.betterMethod    null  avgt   50  3,085 ± 0,048
> ns/op
>
> EqualsIgnoreCaseBenchmark.defaultMethod   true  avgt   50  9,931 ± 0,257
> ns/op
> EqualsIgnoreCaseBenchmark.defaultMethod  false  avgt   50  3,367 ± 0,003
> ns/op
> EqualsIgnoreCaseBenchmark.defaultMethod   null  avgt   50  2,631 ± 0,002
> ns/op
>
> 22.03.2018, 19:35, "Martin Buchholz" <martinrb at google.com>:
> If parseBoolean is worth optimizing (barely, but only because Boolean is
> very popular), then let's do the usual ASCII bit-twiddling:
>
>     public static boolean parseBoolean(String s) {
>         // return "true".equalsIgnoreCase(s);
>         return s != null
>             && s.length() == 4
>             && (s.charAt(0) | 0x20) == 't'
>             && (s.charAt(1) | 0x20) == 'r'
>             && (s.charAt(2) | 0x20) == 'u'
>             && (s.charAt(3) | 0x20) == 'e';
>     }
>
> ModuleBootstrap is not worth changing because any system property is very
> unlikely to be set - the null check will trip 99.9999% of the time.
>
> Units
> EqualsIgnoreCaseBenchmark.bestMethod      true  avgt   50  5,552 ± 0,070
>  ns/op
> EqualsIgnoreCaseBenchmark.bestMethod     false  avgt   50  2,703 ± 0,054
>  ns/op
> EqualsIgnoreCaseBenchmark.bestMethod      null  avgt   50  2,248 ± 0,076
>  ns/op
>
> EqualsIgnoreCaseBenchmark.betterMethod    true  avgt   50  5,072 ± 0,626
>  ns/op
> EqualsIgnoreCaseBenchmark.betterMethod   false  avgt   50  2,955 ± 0,072
>  ns/op
> EqualsIgnoreCaseBenchmark.betterMethod    null  avgt   50  2,416 ± 0,040
>  ns/op
>
> EqualsIgnoreCaseBenchmark.defaultMethod   true  avgt   50  8,986 ± 0,159
>  ns/op
> EqualsIgnoreCaseBenchmark.defaultMethod  false  avgt   50  2,912 ± 0,162
>  ns/op
> EqualsIgnoreCaseBenchmark.defaultMethod   null  avgt   50  2,186 ± 0,027
>  ns/op
>
> and for JDK 10
>
> Benchmark                                (str)  Mode  Cnt  Score   Error
>  Units
> EqualsIgnoreCaseBenchmark.bestMethod      true  avgt   50  5,672 ± 0,071
>  ns/op
> EqualsIgnoreCaseBenchmark.bestMethod     false  avgt   50  3,120 ± 0,040
>  ns/op
> EqualsIgnoreCaseBenchmark.bestMethod      null  avgt   50  2,705 ± 0,060
>  ns/op
>
> EqualsIgnoreCaseBenchmark.betterMethod    true  avgt   50  5,141 ± 0,080
>  ns/op
> EqualsIgnoreCaseBenchmark.betterMethod   false  avgt   50  3,436 ± 0,049
>  ns/op
> EqualsIgnoreCaseBenchmark.betterMethod    null  avgt   50  3,085 ± 0,048
>  ns/op
>
> EqualsIgnoreCaseBenchmark.defaultMethod   true  avgt   50  9,931 ± 0,257
>  ns/op
> EqualsIgnoreCaseBenchmark.defaultMethod  false  avgt   50  3,367 ± 0,003
>  ns/op
> EqualsIgnoreCaseBenchmark.defaultMethod   null  avgt   50  2,631 ± 0,002
>  ns/op
>
> 22.03.2018, 19:35, "Martin Buchholz" <martinrb at google.com>:
>
> If parseBoolean is worth optimizing (barely, but only because Boolean is
> very popular), then let's do the usual ASCII bit-twiddling:
>
>     public static boolean parseBoolean(String s) {
>         // return "true".equalsIgnoreCase(s);
>         return s != null
>             && s.length() == 4
>             && (s.charAt(0) | 0x20) == 't'
>             && (s.charAt(1) | 0x20) == 'r'
>             && (s.charAt(2) | 0x20) == 'u'
>             && (s.charAt(3) | 0x20) == 'e';
>     }
>
> ModuleBootstrap is not worth changing because any system property is very
> unlikely to be set - the null check will trip 99.9999% of the time.
>
>
>