On Tue, 23 Jul 2024 02:48:56 GMT, Shaojin Wen wrote:
>> Currently, about 25% of the time spent by the Integer.parseInt and
>> Long.parseLong methods is spent on the Character.digit method.
>>
>> The Character.digit method is common to all radixes. We can use a digit
>> method optimized for Lat
> Currently, about 25% of the time spent by the Integer.parseInt and
> Long.parseLong methods is spent on the Character.digit method.
>
> The Character.digit method is common to all radixes. We can use a digit
> method optimized for Latin1 encoding radix 10 to improve the performance of
> Integ
> Currently, about 25% of the time spent by the Integer.parseInt and
> Long.parseLong methods is spent on the Character.digit method.
>
> The Character.digit method is common to all radixes. We can use a digit
> method optimized for Latin1 encoding radix 10 to improve the performance of
> Integ
On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen wrote:
>> Currently, about 25% of the time spent by the Integer.parseInt and
>> Long.parseLong methods is spent on the Character.digit method.
>>
>> The Character.digit method is common to all radixes. We can use a digit
>> method optimized for Lat
On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen wrote:
>> Currently, about 25% of the time spent by the Integer.parseInt and
>> Long.parseLong methods is spent on the Character.digit method.
>>
>> The Character.digit method is common to all radixes. We can use a digit
>> method optimized for Lat
On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen wrote:
>> Currently, about 25% of the time spent by the Integer.parseInt and
>> Long.parseLong methods is spent on the Character.digit method.
>>
>> The Character.digit method is common to all radixes. We can use a digit
>> method optimized for Lat
On Sat, 13 Jul 2024 00:50:18 GMT, Shaojin Wen wrote:
>> Currently, about 25% of the time spent by the Integer.parseInt and
>> Long.parseLong methods is spent on the Character.digit method.
>>
>> The Character.digit method is common to all radixes. We can use a digit
>> method optimized for Lat
> Currently, about 25% of the time spent by the Integer.parseInt and
> Long.parseLong methods is spent on the Character.digit method.
>
> The Character.digit method is common to all radixes. We can use a digit
> method optimized for Latin1 encoding radix 10 to improve the performance of
> Integ
Currently, about 25% of the time spent by the Integer.parseInt and
Long.parseLong methods is spent on the Character.digit method.
The Character.digit method is common to all radixes. We can use a digit method
optimized for Latin1 encoding radix 10 to improve the performance of
Integer.parseInt
> By extracting the code that creates the exception, the CodeSize of these
> methods is less than the default FreqInlineSize 325. and for the scenario
> where the most commonly used radix is not specified and the String coder is
> LATIN1, fast-path can improves the performance 10% of
> parseIn
On Thu, 12 Oct 2023 09:55:15 GMT, Shaojin Wen wrote:
>> CharacterDataLatin1.digit is for multi-radix, and the performance when radix
>> = 10 is not good enough.
>
> If we reuse CharacterDataLatin1#DIGITS, the performance will be slower, the
> performance numbers are as follows
>
>
> class Cha
On Thu, 12 Oct 2023 09:19:35 GMT, Shaojin Wen wrote:
>> Let's not forget that `Character.digit()` has a pretty decent fast path for
>> Latin1, including a 256 bytes lookup-table.
>
> CharacterDataLatin1.digit is for multi-radix, and the performance when radix
> = 10 is not good enough.
If we r
On Thu, 12 Oct 2023 09:10:30 GMT, Raffaello Giulietti
wrote:
>> This patch should have little impact on exception-path performance. Remember
>> String concatenation is done with StringBuilder in java.base, so changing
>> formatter to that might have some performance difference. However, the ma
On Thu, 12 Oct 2023 08:58:18 GMT, Chen Liang wrote:
>> While only optimizing the fast path is a good idea, I think it is important
>> to make sure there is no regression on the slow path - as @schlosna pointed
>> out, it's a common way to check if a string can be converted to an int.
>
> This p
On Thu, 12 Oct 2023 08:47:09 GMT, Hannes Greule wrote:
>> More explicitly I was thinking something like below.
>>
>> I do wonder if some of the benchmark tests should cover the exceptional
>> cases. I have seen many systems where attempting to try and parse
>> potentially invalid inputs can h
On Thu, 12 Oct 2023 00:39:27 GMT, David Schlosnagle wrote:
>> He means to pull the `radix< Character,MIN_RADIX` and `radix >
>> Character.MAX_RADIX` shared code in Integer and Long.parseInt (with radix
>> version) to a helper method.
>
> More explicitly I was thinking something like below.
>
On Thu, 12 Oct 2023 02:24:20 GMT, Shaojin Wen wrote:
>> More explicitly I was thinking something like below.
>>
>> I do wonder if some of the benchmark tests should cover the exceptional
>> cases. I have seen many systems where attempting to try and parse
>> potentially invalid inputs can hit
On Tue, 10 Oct 2023 10:22:18 GMT, Chen Liang wrote:
>> parseInt & parseLong are accelerated by this code, the key code is here
>>
>> class DecimalDigits {
>> public static int digit(byte ch) {
>> return DIGITS_LATIN1[ch & 0xFF]; // If remove & 0xFF it won't get
>> faster
>> }
>>
On Tue, 10 Oct 2023 02:54:05 GMT, Shaojin Wen wrote:
> By extracting the code that creates the exception, the CodeSize of these
> methods is less than the default FreqInlineSize 325. and for the scenario
> where the most commonly used radix is not specified and the String coder is
> LATIN1, f
On Tue, 10 Oct 2023 10:03:52 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/Integer.java line 682:
>>
>>> 680: */
>>> 681: public static int parseInt(String s) throws NumberFormatException {
>>> 682: if (s != null && s.coder() == String.LATIN1) {
>>
>> Does th
On Tue, 10 Oct 2023 08:07:37 GMT, Chen Liang wrote:
>> By extracting the code that creates the exception, the CodeSize of these
>> methods is less than the default FreqInlineSize 325. and for the scenario
>> where the most commonly used radix is not specified and the String coder is
>> LATIN1
On Tue, 10 Oct 2023 02:54:05 GMT, Shaojin Wen wrote:
> By extracting the code that creates the exception, the CodeSize of these
> methods is less than the default FreqInlineSize 325. and for the scenario
> where the most commonly used radix is not specified and the String coder is
> LATIN1, f
On Thu, 12 Oct 2023 00:14:45 GMT, Chen Liang wrote:
>> Code style should be consistent
>
> He means to pull the `radix< Character,MIN_RADIX` and `radix >
> Character.MAX_RADIX` shared code in Integer and Long.parseInt (with radix
> version) to a helper method.
More explicitly I was thinking so
On Thu, 12 Oct 2023 00:39:27 GMT, David Schlosnagle wrote:
>> He means to pull the `radix< Character,MIN_RADIX` and `radix >
>> Character.MAX_RADIX` shared code in Integer and Long.parseInt (with radix
>> version) to a helper method.
>
> More explicitly I was thinking something like below.
>
On Thu, 12 Oct 2023 00:06:30 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/Integer.java line 560:
>>
>>> 558: if (radix > Character.MAX_RADIX) {
>>> 559: throw NumberFormatException.forMaxRadix(radix);
>>> 560: }
>>
>> It sounds like these methods
On Wed, 11 Oct 2023 10:30:26 GMT, David Schlosnagle wrote:
>> By extracting the code that creates the exception, the CodeSize of these
>> methods is less than the default FreqInlineSize 325. and for the scenario
>> where the most commonly used radix is not specified and the String coder is
>>
By extracting the code that creates the exception, the CodeSize of these
methods is less than the default FreqInlineSize 325. and for the scenario
where the most commonly used radix is not specified and the String coder is
LATIN1, fast-path can improves the performance 10% of
parseInt(String)/
On Tue, 10 Oct 2023 02:54:05 GMT, Shaojin Wen wrote:
> By extracting the code that creates the exception, the CodeSize of these
> methods is less than the default FreqInlineSize 325. and for the scenario
> where the most commonly used radix is not specified and the String coder is
> LATIN1, f
28 matches
Mail list logo
