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
