My assumption is based on conclusions drawn from this article: https://shipilev.net/blog/2016/arrays-wisdom-ancients/
I don't think the situation has changed much since then. However, I'll do separate benchmarking with the latest JDK just in case. 25.04.2019, 11:24, "Ivan Gerasimov" <ivan.gerasi...@oracle.com>: > Hi Sergei! > > Thanks for sharing. > > However, it's not immediately obvious to me why the later is better than > the former. Can you please elaborate on that? > > I think, it worth a separate discussion. > > With kind regards, > > Ivan > > On 4/25/19 12:40 AM, Сергей Цыпанов wrote: >> 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 > > -- > With kind regards, > Ivan Gerasimov
