[intrinsics]: performance before after (String::format)

Hannes Wallnöfer hannes.wallnoefer at oracle.com
Mon Feb 25 14:56:37 UTC 2019


Hi Vicente, thanks for the extended benchmark results! I think you didn’t attach your benchmark source, those would be very interesting to see.

I can provide explanations for some of the different levels of speedup between formatter conversions and arg types, but not for the performance degradation for large numbers of parameters.

- When formatting to a String (as opposed to a java.lang.Appendable) and the format string does not include conversions that are Locale-dependent or otherwise require Formatter logic, the MethodHandle is built using j.l.invoke.StringConcatFactory, either passing arguments through directly or through a simple formatting handle. This is where you see the huge performance improvements.

- Some conversions like floats or time/date are highly Locale specific. In those cases we always create a Formatter to generate the output. This explains the relatively small performance improvements which come from removed boxing and directly calling into the type specific formatter methods.

- In the last patch I sent you I actually removed some useful optimisations from the Appendable-based implementation. I’ll send you another patch later today that re-adds them (along with some other changes). You should see some improvement in some of the benchmarks, but I don’t think it has anything to do with the degradation for lots of parameters.

Hannes


> Am 22.02.2019 um 18:33 schrieb Vicente Romero <vicente.romero at oracle.com>:
> 
> Hi,
> 
> I have executed some performance tests on the intrinsics code to compare the before and after. Please find the benchmark results and the JMH based benchmark attached. This benchmark is based on a previous one written by Hannes. The benchmark compares the execution between the JDK built from [1], referred here as JDK13, and [2] which is the amber repo, branch `intrinsics-project`.
> 
> Some conclusions from the benchmark results:
> 
> * the intrinsified code is faster in all cases, for which intrinsified
>   code is produced, compared to the legit (JDK13 vanilla) code
> * there are wide variations though
> 
> For example for the test: `testStringFormatBoxedArray` which is basically benchmarking the performance of: `String.format("%s: %d ", args);` where args is: `static final Object[] args = { "Bob", i23 };`, there is basically no visible gain as in this case the intrinsification is bailing out and producing same code as vanilla JDK13. This result is expected. The next test with not so much gain is: `testStringFormat1ConstantFloat` which is testing:
> 
>     `String.format("%g", 1.0)`
> 
> the execution is ~2.5 times faster in the intrinsified version but nothing compared to: `testStringFormat1ConstantStr` which is ~40 times faster. Another interesting conclusion is that the improvement fades out with the number of parameters for some cases but keeps constant for others. For example it is as fast to concatenate 1 or 100 strings but formating one primitive int is ~45 times faster vs a 3.5 improvement when formating a hundred.
> 
> I have also attached the table I used to play with the numbers.
> 
> Thanks,
> 
> Vicente
> 
> [1] http://hg.openjdk.java.net/jdk/jdk
> 
> [2] http://hg.openjdk.java.net/amber/amber
> 
> <benchmarksResults.txt>



More information about the amber-dev mailing list