Сергей: 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@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@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@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@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.