RFR(xs): JDK-8247605 Avoid array allocation when concatenating with empty string

Claes Redestad claes.redestad at oracle.com
Mon Jun 15 17:21:23 UTC 2020


Hi Tagir,

changes looks good to me.

Thanks!

/Claes

On 2020-06-15 18:45, Tagir Valeev wrote:
> Hello!
> 
> Please review the following small change in StringConcatHelper::simpleConcat
> https://bugs.openjdk.java.net/browse/JDK-8247605
> https://cr.openjdk.java.net/~tvaleev/webrev/8247605/r1/
> 
> This change improves the concatenation of empty string and non-empty
> string/object by reusing the internal byte[] array.
> 
> Simple benchmark (StringConcat::concatEmptyRight and
> StringConcat::concatEmptyLeft) shows the significant performance
> improvement in both cases when an empty string is prefixed or
> suffixed. Before patch:
> 
> Benchmark                      (intValue)  Mode  Cnt   Score   Error  Units
> StringConcat.concatEmptyLeft         4711  avgt   30  18,416 ± 0,081  ns/op
> StringConcat.concatEmptyRight        4711  avgt   30  18,439 ± 0,068  ns/op
> StringConcat.concatEmptyLeft:·gc.alloc.rate.norm
> 4711  avgt   10    48,003 ±   0,001    B/op
> StringConcat.concatEmptyRight:·gc.alloc.rate.norm
> 4711  avgt   10    48,003 ±   0,001    B/op
> 
> 
> After patch:
> Benchmark                      (intValue)  Mode  Cnt  Score   Error  Units
> StringConcat.concatEmptyLeft         4711  avgt   30  7,846 ± 0,069  ns/op
> StringConcat.concatEmptyRight        4711  avgt   30  6,800 ± 0,082  ns/op
> StringConcat.concatEmptyLeft:·gc.alloc.rate.norm
> 4711  avgt   10    24,001 ±   0,001    B/op
> StringConcat.concatEmptyRight:·gc.alloc.rate.norm
> 4711  avgt   10    24,001 ±   0,001    B/op
> 
> Note that the allocation and array copying time is O(N) where N is the
> length of non-empty string, so for longer strings, the difference
> could be bigger. No performance degradation was noticed by me in other
> StringConcat benchmarks.
> 
> Previous discussion:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067217.html
> 
> With best regards,
> Tagir Valeev.
> 


More information about the core-libs-dev mailing list