Hi Claes!
On 4/25/19 4:51 AM, Claes Redestad wrote:
Hi Ivan,
the changes and fast-path speed-ups look reasonable, but I'd like to see
that the overhead for cases not helped by the fast paths isn't
excessive, e.g., micro variants with UTF16 Strings and a mix of Latin1
and UTF16.
Good point! After adding a few more micro-benchmarks with UTF16
strings, I realized that it can actually make sense to improve the
UTF16/mixed branch as well.
I'll send the updated webrev shortly.
With kind regards,
Ivan
/Claes
On 2019-04-25 08:00, Ivan Gerasimov wrote:
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
