On Tue, 7 Feb 2023 19:10:08 GMT, Francesco Nigro wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyrights
>
> Thanks @cl4es to look into this!
@franz1981 idea seems to apply nicely here, and going back and
On Tue, 7 Feb 2023 20:32:11 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/String.java line 698:
>>
>>> 696: }
>>> 697:
>>> 698: static byte[] copyBytes(byte[] bytes, int offset, int length) {
>>
>> Given that the stub generated for array copy seems highly
On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad wrote:
>> This adds a local, specialized `copyBytes` method to `String` that avoids
>> certain redundant range checks and clamping that JIT has issues removing
>> fully.
>>
>> This has a small but statistically significant effect on `String`
>>
On Tue, 7 Feb 2023 19:08:59 GMT, Francesco Nigro wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyrights
>
> src/java.base/share/classes/java/lang/String.java line 698:
>
>> 696: }
>> 697:
>> 698:
On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad wrote:
>> This adds a local, specialized `copyBytes` method to `String` that avoids
>> certain redundant range checks and clamping that JIT has issues removing
>> fully.
>>
>> This has a small but statistically significant effect on `String`
>>
On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad wrote:
>> This adds a local, specialized `copyBytes` method to `String` that avoids
>> certain redundant range checks and clamping that JIT has issues removing
>> fully.
>>
>> This has a small but statistically significant effect on `String`
>>
On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad wrote:
>> This adds a local, specialized `copyBytes` method to `String` that avoids
>> certain redundant range checks and clamping that JIT has issues removing
>> fully.
>>
>> This has a small but statistically significant effect on `String`
>>
On Tue, 7 Feb 2023 19:24:11 GMT, Stuart Marks wrote:
> > It might be that the redundant checks in Arrays.copyOfRange would be
> > eliminated properly with more inlining, and that the issue here is that the
> > affected String constructor is particularly gnarly. This gnarliness is due
> > 1)
On Tue, 7 Feb 2023 19:12:38 GMT, Claes Redestad wrote:
> It might be that the redundant checks in Arrays.copyOfRange would be
> eliminated properly with more inlining, and that the issue here is that the
> affected String constructor is particularly gnarly. This gnarliness is due 1)
> the
On Tue, 7 Feb 2023 18:35:32 GMT, John R Rose wrote:
> Our source code is a reference implementation, and people will look at this
> change as evidence that `Arrays::copyOfRange` should be hand-inlined by savvy
> coders. Surely we could also fix this small performance pothole by improving
>
On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad wrote:
>> This adds a local, specialized `copyBytes` method to `String` that avoids
>> certain redundant range checks and clamping that JIT has issues removing
>> fully.
>>
>> This has a small but statistically significant effect on `String`
>>
On Tue, 7 Feb 2023 15:25:05 GMT, Claes Redestad wrote:
>> This adds a local, specialized `copyBytes` method to `String` that avoids
>> certain redundant range checks and clamping that JIT has issues removing
>> fully.
>>
>> This has a small but statistically significant effect on `String`
>>
> This adds a local, specialized `copyBytes` method to `String` that avoids
> certain redundant range checks and clamping that JIT has issues removing
> fully.
>
> This has a small but statistically significant effect on `String`
> microbenchmarks, eg.:
>
> Baseline
>
> Benchmark
13 matches
Mail list logo
