String concatenation tweaks

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Jun 4 12:01:15 UTC 2015


Yeah - noticed that.

One more question. I guess baseline is vanilla javac, while all the 
others are using indy (as you explain in your notes very well). How 
about also running a benchmark with the original patch proposed in this 
thread, which doesn't do indy, but only precomputes sizes where possible?

Maurizio

On 04/06/15 12:56, Aleksey Shipilev wrote:
> On 06/04/2015 02:50 PM, Maurizio Cimadamore wrote:
>> So, if I parse correctly, it seems that either FULL_MH and
>> NAIVE_MH_FILTER_SIZED wins on large size, but are considerably slower at
>> lower sizes. On the other hand, INNER_SIZED seems like the best across
>> the board?
> Yup, except for a tiny thing on size=1:
>
> # BASELINE
> ConcatBench.string_string_long:  32.095 ±    0.374   ns/op
>
> # INNER
> ConcatBench.string_string_long:  32.233 ±    0.276   ns/op
>
> # INNER_SIZED:
> ConcatBench.string_string_long:  45.854 ±    0.729   ns/op
>
> That's a price you pay for redundantly computing the final length, when
> the default length (16) is enough.
>
> Thanks,
> -Aleksey
>
>
>



More information about the compiler-dev mailing list