String.indexOf(single-char-String)

[Michael Bien]

On 23.11.21 15:57, Roger Riggs wrote:
> Hi Michael,
>
> As you might expect performance of strings is very sensitive and has 
> been tuned extensively over the years many times.
>
> Though this improves the performance for 1 character strings. It will 
> have an impact on *every other* length of string.
> You'll need to show that it does not impact performance of longer 
> strings.

yes of course. The if (str.length == 1) branch should be dead code and 
eliminated by the JVM for all String constants with non-one lengths.

Looking through the benchmarks in micro/*/java/lang/String*, all seem to 
be using constants as parameter for indexOf(). To try to measure the 
impact of the if branch i would have to write a benchmark with a 
parameter which changes every iteration, right? Otherwise the branch 
will be optimized away by the JIT.

>
> It may be worth looking further at other ways to achieve the result.

agreed, I tried the most obvious approach first, but there is a chance 
that the fast path can be put into the intrinsified 
StringLatin1/StringUTF16 code instead.

-michael


>
> Regards, Roger
>
>
> On 11/22/21 3:52 PM, Michael Bien wrote:
>> Hello,
>>
>> I kept forgetting which variants of the String methods perform better 
>> with single-char-Strings and which with char (IDEs had the tendency 
>> to suggest the wrong variant since it changed between JDK releases). 
>> So i wrote JMH benchmarks and noticed that the last method with a 
>> performance difference seems to be String.indexOf() - all other 
>> variants performed equally (unless I overlooked some).
>>
>> this might be fairly easy to fix:
>>
>> https://github.com/openjdk/jdk/pull/6509
>>
>> (side effect: contains("c") is also faster)
>>
>> I haven't looked into the intrinsified code of StringLatin1 and 
>> StringUTF16 to check if it could be fixed there (mostly because i 
>> actually don't know how the JVM assembles those intrinsics). It might 
>> be possible to improve this for short Strings in general, not just 
>> for chars, dependent on why the intrinsified version is actually 
>> slower for single-char-Strings. I opted for the trivial fix in java 
>> code.
>>
>> best regards,
>>
>> michael
>>
>