Hi Jason,
Thanks for checking, the difference of the utf16 numbers seemed to be
just outside of the error range.
Regards, Roger
On 9/9/20 3:17 PM, Tatton, Jason wrote:
Hi Roger,
Thanks for your question. The code path for UTF16 has hasn't been interacted
with in a meaningful way in this
Hi Roger,
Thanks for your question. The code path for UTF16 has hasn't been interacted
with in a meaningful way in this patch so I think this is just noise. To
validate this hypothesis I re-ran the benchmark with 10 forks (default is 5),
the results indicate that the performance of the UTF16
Hi Jason,
With respect to the increased ns/op in the utf16_mixed_char benchmark,
how should we understand the lower performance?
Thanks, Roger
On 9/8/20 8:02 AM, Tatton, Jason wrote:
Hi Andrew, thank you for taking the time to review this.
Since we have now moved to git, I have raised a new
Hi Andrew, thank you for taking the time to review this.
Since we have now moved to git, I have raised a new PR for this RFR:
https://github.com/openjdk/jdk/pull/71
https://bugs.openjdk.java.net/browse/JDK-8173585
I have improved the micro benchmark in the ways which you and others have
On 03/09/2020 22:28, Tatton, Jason wrote:
>
> JMH Benchmark results:
>
> The benchmarks examine the 3 codepaths for StringLatin1 and
> StringUTF16. Here are the results for Intel x86 (ARM is similar):
>
> FYI, String lengths in characters (1byte for Latin1, 2bytes for UTF16):
