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