String.equalsIgnoreCase(...) optimization

[Andrey]

Results for long strings

    private static final String _STRING = "This test needs to be better. Always comparing String and string doesn't tell us much. These strings are extremely short, and a few more cases would be useful. Please change your units to something more sensible. I suggest nanoseconds. Thanks, Andrew.";
    private static final String STRING = "THIS TEST NEEDS TO BE BETTER. ALWAYS COMPARING STRING AND STRING DOESN'T TELL US MUCH. THESE STRINGS ARE EXTREMELY SHORT, AND A FEW MORE CASES WOULD BE USEFUL. PLEASE CHANGE YOUR UNITS TO SOMETHING MORE SENSIBLE. I SUGGEST NANOSECONDS. THANKS, ANDREW.";


# Run complete. Total time: 00:04:01

Benchmark Mode Cnt Score Error Units
StringBenchmark.constConst        thrpt 20   931938,920 ± 1703,527 ops/s
StringBenchmark.constConstFast thrpt 20 1290645,530 ± 10855,059 ops/s
StringBenchmark.newNew            thrpt 20 604461,665 ± 17613,802 ops/s
StringBenchmark.newNewFast     thrpt 20 962488,540 ± 15299,433 ops/s
StringBenchmark.varVar               thrpt 20   849925,016 ± 1933,533 ops/s
StringBenchmark.varVarFast        thrpt 20 1306144,917 ± 15554,201 ops/s

For not equal strings algorithm has performance as standard String.equalsIgnoreCase(...) .

27.04.2016, 13:17, "Andrew Haley" <aph at redhat.com>:
>  On 27/04/16 10:57, Andrey wrote:
>
>>   I publish my JMH benchmark at github
>>   https://github.com/volodin-aa/openjdk-benchmark
>
>  This test needs to be better. Always comparing "String" and "string"
>  doesn't tell us much. These strings are extremely short, and a few
>  more cases would be useful.
>
>  Please change your units to something more sensible. I suggest
>  nanoseconds.
>
>  Thanks,
>
>  Andrew.