On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen wrote:
>> I submitted PR #1 before, and there were too many changes. I split it
>> into multiple PRs with small changes. This one is one of them.
>>
>> this PR removed the duplicate code for getChars in
>> Big
On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen wrote:
>> I submitted PR #1 before, and there were too many changes. I split it
>> into multiple PRs with small changes. This one is one of them.
>>
>> this PR removed the duplicate code for getChars in
>> Big
On Sun, 17 Sep 2023 16:01:33 GMT, Shaojin Wen wrote:
> @cl4es made performance optimizations for the simple specifiers of
> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
> same idea, I continued to make improvements. I made patterns like %2d %02
On Mon, 25 Sep 2023 11:46:36 GMT, Claes Redestad wrote:
> > The reason why I split it into multiple small methods is to avoid a single
> > method codeSize > 325. After merging small methods, the performance will
> > decrease.
>
> Yes, I can refactor to keep the same structure and verify
1. Reduce duplicate stringSize code
2. Move java.lang.StringLatin1.getChars to
jdk.internal.util.DecimalDigits::getCharLatin1，not only java.lang, other
packages also need to use this method
-
Commit messages:
- Revert FormatItem related changes
- restore
@cl4es made performance optimizations for the simple specifiers of
String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same
idea, I continued to make improvements. I made patterns like %2d %02d also be
optimized.
The following are the test results based on MacBookPro M1
On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen wrote:
>> I submitted PR #1 before, and there were too many changes. I split it
>> into multiple PRs with small changes. This one is one of them.
>>
>> this PR removed the duplicate code for getChars in
>> Big
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
Use StringConcatFactory.makeConcatWithConstants
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16006/fi
On Thu, 28 Sep 2023 15:01:25 GMT, Raffaello Giulietti
wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refactor according to rgiulietti's suggestion and add testcases
>
> Meaningful
On Fri, 22 Sep 2023 11:53:18 GMT, Andriy Plokhotnyuk wrote:
>> 1. Reduce duplicate stringSize code
>> 2. Move java.lang.StringLatin1.getChars to
>> jdk.internal.util.DecimalDigits::getCharLatin1，not only java.lang, other
>> packages also need to use this method
>
>
On Mon, 25 Sep 2023 12:28:06 GMT, Claes Redestad wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like %2d %02d
>> also be
On Tue, 19 Sep 2023 16:15:12 GMT, Roger Riggs wrote:
> There's a lot of duplication exposed here between the `digits` method and the
> `getCharsLatin1` method that should be resolved. Can the callers of
> `getCharsLatin1` be converted to use `digits`?
>
> We also should keep HexDigits and
On Mon, 25 Sep 2023 12:20:36 GMT, Shaojin Wen wrote:
>>> The reason why I split it into multiple small methods is to avoid a single
>>> method codeSize > 325. After merging small methods, the performance will
>>> decrease.
>>
>> Yes, I can refa
On Wed, 13 Sep 2023 01:24:05 GMT, Shaojin Wen wrote:
> 1. Reduce duplicate stringSize code
> 2. Move java.lang.StringLatin1.getChars to
> jdk.internal.util.DecimalDigits::getCharLatin1，not only java.lang, other
> packages also need to use this method
@cl4es can you help me to re
On Fri, 22 Sep 2023 12:09:48 GMT, Jim Laskey wrote:
>> src/java.base/share/classes/java/util/FormatItem.java line 148:
>>
>>> 146: int length = DecimalDigits.stringSize(value);
>>> 147: this.digits = new byte[length];
>>> 148:
On Wed, 27 Sep 2023 19:51:25 GMT, Raffaello Giulietti
wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like %2d %02d
>>
> j.u.Formatter now prints "%tF" (iso standard date) and the result is
> incorrect when processing year < 0 or year >
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
fix typo
-
C
On Fri, 22 Sep 2023 04:46:36 GMT, Chen Liang wrote:
> Do Octal and Hex digits need int versions of getChars and stringSize?
Since DecimalDigits made this change, for consistency, Octal and Hex digits
also do the same thing.
-
PR Comment:
On Mon, 16 Oct 2023 20:36:42 GMT, Naoto Sato wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> No longer localize printed numbers
>
> test/jdk/java/util/Formatter/BasicDat
On Mon, 18 Sep 2023 00:48:26 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/util/Formatter.java line 3420:
>>
>>> 3418: && fmt.a instanceof StringBuilder sb
>>> 3419: ) {
>>> 3420: sb.ap
When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use
try...catch to handle CharacterCodingException and throw
IllegalArgumentException instead of CharacterCodingException to make the
calling code cleaner.
-
Commit messages:
- Make the NoRepl methods
> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
> use try...catch to handle CharacterCodingException and throw
> IllegalArgumentException instead of CharacterCodingException to make the
> calling code cleaner.
Shaojin Wen has updated the pull request i
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
use % calculate lowInt
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16006/files
- new: https://git.openjdk.
> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
> use try...catch to handle CharacterCodingException and throw
> IllegalArgumentException instead of CharacterCodingException to make the
> calling code cleaner.
Shaojin Wen has updated the pull request i
> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
> use try...catch to handle CharacterCodingException and throw
> IllegalArgumentException instead of CharacterCodingException to make the
> calling code cleaner.
Shaojin Wen has updated the pull request i
On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen wrote:
>> I submitted PR #1 before, and there were too many changes. I split it
>> into multiple PRs with small changes. This one is one of them.
>>
>> this PR removed the duplicate code for getChars in
>> Big
> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
> use try...catch to handle CharacterCodingException and throw
> IllegalArgumentException instead of CharacterCodingException to make the
> calling code cleaner.
Shaojin Wen has updated the pull request i
On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen wrote:
>> I submitted PR #1 before, and there were too many changes. I split it
>> into multiple PRs with small changes. This one is one of them.
>>
>> this PR removed the duplicate code for getChars in
>> Big
On Tue, 17 Oct 2023 14:09:08 GMT, Raffaello Giulietti
wrote:
> @wenshao The proposal changes the exception types for seemingly no reason.
> What concrete problem does this enhancement PR address?
@lianch 's suggestion in PR #14812 :
"Make the NoRepl methods throw IllegalArgument (like
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
remove JLA
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16006/files
- new: https://git.openjdk.org/jd
> j.u.Formatter now prints "%tF" (iso standard date) and the result is
> incorrect when processing year < 0 or year >
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
use DecimalFormatSymbols#getMinusSign
On Tue, 7 Nov 2023 15:04:16 GMT, Roger Riggs wrote:
>> While it might be reasonable to localize using `getMinusSign()` this will
>> introduce a new inconsistency with `DateTimeFormatter` (which *does not*
>> localize minus signs in front of years):
>>
>> int minus =
On Sat, 21 Oct 2023 01:22:04 GMT, Shaojin Wen wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like
> j.u.Formatter now prints "%tF" (iso standard date) and the result is
> incorrect when processing year < 0 or year >
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
Use minus sign from cached DecimalForm
On Thu, 28 Sep 2023 15:01:25 GMT, Raffaello Giulietti
wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like %2d %02d
>>
> j.u.Formatter now prints "%tF" (iso standard date) and the result is
> incorrect when processing year < 0 or year >
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
revert localize change
-
C
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
recipe ("\1.\1\1")
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16006/files
- new: https://git.open
)
> +StringFormat.stringFormat avgt 15 62.619 ? 4.652 ns/op (+2.19)
> +StringFormat.stringIntFormat avgt 15 89.606 ? 13.966 ns/op (-2.44)
> +StringFormat.widthStringFormat avgt 15 52.462 ? 15.649 ns/op
> (+377.95)
> +StringFormat.widthStringIntF
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
fix from @cl4es 's review
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16006/files
- new: https://git.op
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
fix from @cl4es 's review
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16006/files
- new: https://git.op
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
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
On Wed, 11 Oct 2023 09:48:58 GMT, Claes Redestad wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> refactor based on @liach 's review
>
> src/java.base/share/classes/java/math/BigDeci
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
>>
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
On Wed, 11 Oct 2023 09:50:20 GMT, Claes Redestad wrote:
> I'm not really qualified to review the floating point code. Simplifying away
> offset and getting rid of the StringBuilderHelper all seem like good
> improvements, though I think it'd be good if we could either avoid or split
> out the
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
>>
On Wed, 11 Oct 2023 22:10:45 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/math/BigDecimal.java line 4168:
>>
>>> 4166: int lowInt = (int)intCompact % 100;
>>> 4167: int highInt = (int)intCompact / 100;
>>> 4168:
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
On Mon, 9 Oct 2023 23:21:57 GMT, Shaojin Wen wrote:
>> j.u.Formatter now prints "%tF" (iso standard date) and the result is
>> incorrect when processing year < 0 or year >
>
> Shaojin Wen has updated the pull request incrementally with one additional
On Fri, 6 Oct 2023 14:20:13 GMT, Claes Redestad wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update full name
>
> FWIW I'll not review or sponsor any PRs that use `ByteArrayLitt
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 no
On Fri, 15 Sep 2023 18:04:29 GMT, Shaojin Wen wrote:
> In the improvement of @cl4es PR #15591, the advantages of non-lookup-table
> were discussed.
>
> But if the input is byte[], using lookup table can improve performance.
>
> For HexFormat#formatHex(Appendable, byt
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
refactor based on @cl4es 's review
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16006/files
- new: https://g
)
> +StringFormat.stringFormat avgt 15 62.619 ? 4.652 ns/op (+2.19)
> +StringFormat.stringIntFormat avgt 15 89.606 ? 13.966 ns/op (-2.44)
> +StringFormat.widthStringFormat avgt 15 52.462 ? 15.649 ns/op
> (+377.95)
> +StringFormat.widthStringIntF
On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen wrote:
>> I submitted PR #1 before, and there were too many changes. I split it
>> into multiple PRs with small changes. This one is one of them.
>>
>> this PR removed the duplicate code for getChars in
>> Big
On Tue, 17 Oct 2023 15:56:58 GMT, Chen Liang wrote:
> Can you export jfr recordings of two different runs to check?
How to do this? I don't know how yet
-
PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1767448022
On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen wrote:
>> I submitted PR #1 before, and there were too many changes. I split it
>> into multiple PRs with small changes. This one is one of them.
>>
>> this PR removed the duplicate code for getChars in
>> Big
On Wed, 18 Oct 2023 15:59:31 GMT, Claes Redestad wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use StringConcatFactory.makeConcatWithConstants
>
> I've opened up #16244 f
On Thu, 28 Sep 2023 15:01:25 GMT, Raffaello Giulietti
wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like %2d %02d
>>
On Mon, 16 Oct 2023 22:27:34 GMT, Shaojin Wen wrote:
> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
> use try...catch to handle CharacterCodingException and throw
> IllegalArgumentException instead of CharacterCodingException to make the
> calling
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brought in
by the merge/rebase. The pull request contains 10 additional commits since
On Fri, 20 Oct 2023 08:52:04 GMT, Raffaello Giulietti
wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix FormatterBuilder testcase handle lineSeparator on windows
>
> src/jav
)
> +StringFormat.stringFormat avgt 15 62.619 ? 4.652 ns/op (+2.19)
> +StringFormat.stringIntFormat avgt 15 89.606 ? 13.966 ns/op (-2.44)
> +StringFormat.widthStringFormat avgt 15 52.462 ? 15.649 ns/op
> (+377.95)
> +StringFormat.widthStringIntF
)
> +StringFormat.stringFormat avgt 15 62.619 ? 4.652 ns/op (+2.19)
> +StringFormat.stringIntFormat avgt 15 89.606 ? 13.966 ns/op (-2.44)
> +StringFormat.widthStringFormat avgt 15 52.462 ? 15.649 ns/op
> (+377.95)
> +StringFormat.widthStringIntF
On Thu, 19 Oct 2023 11:58:26 GMT, Claes Redestad wrote:
>> @cl4es
>>
>>> Good, narrows it down to what's going on in `prepend(long, byte[],
>>> String)`. Might boil down to `System.arraycopy`. This method might not be
>>> optimized for tiny arrays on all platforms. Specializing for
On Thu, 19 Oct 2023 10:22:19 GMT, Raffaello Giulietti
wrote:
>> I've opened up #16244 for review - thanks for helping with analysis and
>> verification.
>
> @cl4es @wenshao I'd like to review the mathematical aspects of these changes
> once the refactorings with string concatenations have
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
reduce duplicate code & code format & refactor benchmark case
-
Changes:
- all: https://git.openjdk.org/jd
On Thu, 19 Oct 2023 11:58:26 GMT, Claes Redestad wrote:
>> @cl4es
>>
>>> Good, narrows it down to what's going on in `prepend(long, byte[],
>>> String)`. Might boil down to `System.arraycopy`. This method might not be
>>> optimized for tiny arrays on all platforms. Specializing for
On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen wrote:
>> I submitted PR #1 before, and there were too many changes. I split it
>> into multiple PRs with small changes. This one is one of them.
>>
>> this PR removed the duplicate code for getChars in
>> Big
On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen wrote:
>> I submitted PR #1 before, and there were too many changes. I split it
>> into multiple PRs with small changes. This one is one of them.
>>
>> this PR removed the duplicate code for getChars in
>> Big
On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen wrote:
>> I submitted PR #1 before, and there were too many changes. I split it
>> into multiple PRs with small changes. This one is one of them.
>>
>> this PR removed the duplicate code for getChars in
>> Big
rformance 10% of
> parseInt(String)/parseLong(String).
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains four commits:
- merge from master
- Merge remote-tracking branch 'upstream/master' into parse_int_long
# Conflic
> j.u.Formatter now prints "%tF" (iso standard date) and the result is
> incorrect when processing year < 0 or year >
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
fix format 'ja-JP-u-ca-jap
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
revert use JLA
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16006/files
- new: https://git.openjdk.org/jd
> j.u.Formatter now prints "%tF" (iso standard date) and the result is
> incorrect when processing year < 0 or year >
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
fix format 'ja-JP-u-ca-jap
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 15 commits:
- merge from master
- Merge remote-tracking branch 'upstream/master' into
optim_decimal_to_string_x1
)
> +StringFormat.stringFormat avgt 15 62.619 ? 4.652 ns/op (+2.19)
> +StringFormat.stringIntFormat avgt 15 89.606 ? 13.966 ns/op (-2.44)
> +StringFormat.widthStringFormat avgt 15 52.462 ? 15.649 ns/op
> (+377.95)
> +StringFormat.widthStringIntF
On Sun, 17 Sep 2023 16:01:33 GMT, Shaojin Wen wrote:
> @cl4es made performance optimizations for the simple specifiers of
> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
> same idea, I continued to make improvements. I made patterns like %2d %02
On Thu, 21 Dec 2023 08:37:23 GMT, Shaojin Wen wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like
)
> +StringFormat.stringFormat avgt 15 62.619 ? 4.652 ns/op (+2.19)
> +StringFormat.stringIntFormat avgt 15 89.606 ? 13.966 ns/op (-2.44)
> +StringFormat.widthStringFormat avgt 15 52.462 ? 15.649 ns/op
> (+377.95)
> +StringFormat.widthStringIntF
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 17 commits:
- Merge remote-tracking branch 'upstream/master' into
optim_decimal_to_string_x1
- revert use JLA
-
e review and don't hesitate to critique my approach and patch.
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 19 commits:
- Merge remote-tracking branch 'upstream/master' into
optim_decimal_to_string_x1
- Merge remote-trackin
> j.u.Formatter now prints "%tF" (iso standard date) and the result is
> incorrect when processing year < 0 or year >
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
add JapaneseChronology testcase
> j.u.Formatter now prints "%tF" (iso standard date) and the result is
> incorrect when processing year < 0 or year >
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
use t.query(TemporalQueries.ch
On Sun, 19 Nov 2023 01:52:13 GMT, Naoto Sato wrote:
>> JapaneseChronology is an IsoChronology so run the test again (before
>> committing) to make sure.
>
> `JapaneseChronology` is not extending `IsoChronology`, and that is the gist
> of the change I suggested.
I added the testcase of
On Thu, 9 Nov 2023 17:15:02 GMT, Naoto Sato wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use minus sign from cached DecimalFormatSymbols and improved testcase
>
> Looks like you
On Mon, 4 Sep 2023 04:58:08 GMT, Shaojin Wen wrote:
> BigDecimal is a commonly used class in business development, It is often
> necessary to perform toString or toPlainString operations on BigDecimal.
>
> The current version uses StringBuilder resulting in multiple memory
>
> j.u.Formatter now prints "%tF" (iso standard date) and the result is
> incorrect when processing year < 0 or year >
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
update copyright
-
C
On Sat, 21 Oct 2023 01:22:04 GMT, Shaojin Wen wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like
On Tue, 3 Oct 2023 21:37:46 GMT, Shaojin Wen wrote:
> j.u.Formatter now prints "%tF" (iso standard date) and the result is
> incorrect when processing year < 0 or year >
This pull request has now been integrated.
Changeset: 61d81d64
Author:Shaojin Wen
Comm
On Wed, 4 Oct 2023 22:30:42 GMT, Shaojin Wen wrote:
> # Goal
> Improve String Template FMT's processing performance of date types.
> Currently, FMT processes date types by toString and then calls
> j.u.Formatter#print. Because there is less parse processing than
>
On Mon, 2 Oct 2023 23:05:29 GMT, Shaojin Wen wrote:
> In the current version, FMT."v =%d{1}" will call the
> StringConcatHelper.prepend(long/byte[]/long) method, which should behave the
> same as STR."v ={1}". Call StringConcatHelper.prepend(long/byte[]/int),
>
On Tue, 3 Oct 2023 06:19:11 GMT, Shaojin Wen wrote:
> Currently FormatItem uses MethodHandler to handle latin1 and utf16, which is
> not readable. This PR uses direct calls instead of MethodHandle.
>
> Please review and don't hesitate to critique my approach and patch.
This pull
reate a char[]
>
>
> boolean isCompact = (len <= MAX_COMPACT_DIGITS); // 18
> if (!isCompact) {
> // ...
> } else {
> char[] coeff = new char[len]; // allocate char[]
> // ...
> }
>
>
> This PR eliminates the two memory allocations mentioned above,
reate a char[]
>
>
> boolean isCompact = (len <= MAX_COMPACT_DIGITS); // 18
> if (!isCompact) {
> // ...
> } else {
> char[] coeff = new char[len]; // allocate char[]
> // ...
> }
>
>
> This PR eliminates the two memory allocations mentioned above,
On Fri, 26 Apr 2024 02:04:38 GMT, Joe Darcy wrote:
>>> @cl4es @jddarcy All feedback has been fixed, can it be integrated?
>>
>> Hello @wenshao ,
>>
>> This change will need additional review from myself or others who maintain
>> BigDecimal before it can be integrated.
>
>> @jddarcy Sorry for
On Fri, 26 Apr 2024 05:48:03 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); //
1 - 100 of 157 matches
Mail list logo
