RFR 8222955 : Optimize String.replace(CharSequence, CharSequence) for Latin1 encoded strings

Claes Redestad claes.redestad at oracle.com
Thu Apr 25 11:51:54 UTC 2019


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.

/Claes

On 2019-04-25 08:00, Ivan Gerasimov wrote:
> Hello!
> 
> This enhancement was inspired by a recent discussion at 
> compiler-dev at 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!
> 


More information about the core-libs-dev mailing list