String concatenation tweaks

Aleksey Shipilev aleksey.shipilev at
Thu Jun 4 10:02:55 UTC 2015

On 06/04/2015 12:46 PM, Maurizio Cimadamore wrote:
> Cool stuff!

Thanks, Maurizio! Can I lure you into reviewing the JEP draft? ;)

> I've looked at your benchmarks in here:
> If I parse correctly, in the string_string_long case the MH version
> (either plain or sized) is slower than baseline with size 100? Why is so?

I think you are reading these in reverse. The benchmark scores are in
ns/op, so the lower the better. It might be confusing the see the
auxiliary allocation data, measured in bytes/op interleaved in the same

FULL_MH and NAIVE_MH_FILTER_SIZED are slower at low sizes, and start to
win on large ones, once they start to guess the final length right, and
compensate for the additional steps to compute the length with that

The goal for current benchmarking was to explore if we can move the code
into runtime without prohibitive performance regressions (and there is
no throughput regressions for INNER!), and to explore if other
strategies can be employed (and they can, but they require more
polishing if we want to switch to them).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the compiler-dev mailing list