80780b6862473
Stats: 24 lines in 1 file changed: 11 ins; 2 del; 11 mod
8302863: Speed up String::encodeASCII using countPositives
Reviewed-by: alanb
-
PR: https://git.openjdk.org/jdk/pull/12640
On Mon, 20 Feb 2023 21:40:41 GMT, Brett Okken wrote:
>> When encoding Strings to US-ASCII we can speed up the happy path
>> significantly by using `StringCoding.countPositives` as a speculative check
>> for whether there are any chars that needs to be replaced by `'?'`. Once a
>> non-ASCII
On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad wrote:
> When encoding Strings to US-ASCII we can speed up the happy path
> significantly by using `StringCoding.countPositives` as a speculative check
> for whether there are any chars that needs to be replaced by `'?'`. Once a
> non-ASCII
On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad wrote:
> When encoding Strings to US-ASCII we can speed up the happy path
> significantly by using `StringCoding.countPositives` as a speculative check
> for whether there are any chars that needs to be replaced by `'?'`. Once a
> non-ASCII
On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad wrote:
> When encoding Strings to US-ASCII we can speed up the happy path
> significantly by using `StringCoding.countPositives` as a speculative check
> for whether there are any chars that needs to be replaced by `'?'`. Once a
> non-ASCII
On Sun, 19 Feb 2023 07:24:30 GMT, David Schlosnagle wrote:
>> When encoding Strings to US-ASCII we can speed up the happy path
>> significantly by using `StringCoding.countPositives` as a speculative check
>> for whether there are any chars that needs to be replaced by `'?'`. Once a
>>
When encoding Strings to US-ASCII we can speed up the happy path significantly
by using `StringCoding.countPositives` as a speculative check for whether there
are any chars that needs to be replaced by `'?'`. Once a non-ASCII char is
encountered we fall back to the slow loop and replace as
On Sat, 18 Feb 2023 23:26:08 GMT, Claes Redestad wrote:
> When encoding Strings to US-ASCII we can speed up the happy path
> significantly by using `StringCoding.countPositives` as a speculative check
> for whether there are any chars that needs to be replaced by `'?'`. Once a
> non-ASCII
Unsafe might be similarly tricky dependency-wise, but perhaps less so. Either
solution might work fine if we extract the code for encoding to a utility class
that isn’t initialized eagerly with String.class itself.
I’ll file an RFE and get the ”trivial” fix to use StringCoding.countPositives
Thanks for taking a look at this.
That is a pretty good improvement with a much smaller change.
I recognize the intricacies of bootstrapping, but have no expertise. Would
using Unsafe directly be easier? Particularly for shorter strings, doing
the copying and checking together rather than as
Hi,
general comment: String might be one of the trickier places to add a VarHandle
dependency, since String is used very early in the bootstrap and depended upon
by everything else, so I’d expect such a solution would have to navigate
potential circularity issues carefully. It’d be good to
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/String.java#L976-L981
For String.encodeASCII, with the LATIN1 coder is there any interest in
exploring the performance impacts of utilizing a
byteArrayViewVarHandle to read/write as longs and utilize a bitmask to
12 matches
Mail list logo
