Hi Ivan, recently looking into java.lang.String I've found out that String::split still uses old collection-to-array approach:
String[] result = new String[resultSize]; return list.subList(0, resultSize).toArray(result); which should be replaced with return list.subList(0, resultSize).toArray(new String[0]); this changes is too small to create a separate ticket for this, so could I ask you to add this into your changes? Regards, Sergei Tsypanov 25.04.2019, 08:04, "Ivan Gerasimov" <ivan.gerasi...@oracle.com>: > Hello! > > This enhancement was inspired by a recent discussion at > compiler-...@openjdk.java.net. > > It seems to be a non-uncommon situation when String.replace(CS, CS) is > called with this and both arguments being Latin1 strings, so it seems > reasonable to optimize for such case. > > Here are the fresh benchmark results (see the webrev for the source of > the benchmark): > -- prior the fix: > Benchmark Mode Cnt Score Error Units > StringReplace.replace1_0 avgt 24 70.860 ± 5.239 ns/op > StringReplace.replace1_1 avgt 24 82.661 ± 1.007 ns/op > StringReplace.replace1_2 avgt 24 97.251 ± 1.186 ns/op > > -- after the fix: > Benchmark Mode Cnt Score Error Units > StringReplace.replace1_0 avgt 24 52.855 ± 0.982 ns/op > StringReplace.replace1_1 avgt 24 23.849 ± 0.066 ns/op > StringReplace.replace1_2 avgt 24 62.266 ± 0.552 ns/op > > So the speedup was x1.3, x3.4, x1.5. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8222955 > WEBREV: http://cr.openjdk.java.net/~igerasim/8222955/00/webrev/ > > Mach5 job is in progress and looks green so far (a few test groups are > left). > > Thanks in advance! > > -- > With kind regards, > Ivan Gerasimov
