Integrated: 8333396: Use StringBuilder internally for java.text.Format.* formatting

2024-07-21 Thread lingjun-cg
On Mon, 3 Jun 2024 04:18:20 GMT, lingjun-cg wrote: > ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic > instructions. But when run with JDK 11, there is no such problem. The reason > is the removed bi

Re: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v17]

2024-07-18 Thread lingjun-cg
On Mon, 8 Jul 2024 16:31:23 GMT, Naoto Sato wrote: >> Quick question about the violation of the "This is equivalent to" spec: Does >> our new implementation lead to any observable side effects that make the >> returned results or thrown exceptions different from that of `format(obj, >> new Str

Re: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v21]

2024-07-14 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v20]

2024-07-14 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v19]

2024-07-09 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v17]

2024-07-08 Thread lingjun-cg
On Mon, 8 Jul 2024 17:31:53 GMT, Justin Lu wrote: > I believe the `static MessageFormat.format(...` also has similar incorrect > "this is equivalent ..." wording, if you could please include that as well. I > think we should also rename the issue (and CSR) as well since the scope has > changed

Re: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v18]

2024-07-08 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v16]

2024-07-07 Thread lingjun-cg
On Fri, 5 Jul 2024 16:54:41 GMT, Justin Lu wrote: > Following up on my previous comment regarding the _untrue wording_. > > I no longer think we can just split the implementation and specification > portion of this PR into two issues, since if we backport the implementation > only, the specifi

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v17]

2024-07-07 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v8]

2024-07-03 Thread lingjun-cg
On Tue, 25 Jun 2024 19:33:02 GMT, Naoto Sato wrote: >> I did not mean to introduce a public API for this change (if we do, the fix >> cannot be backported). I thought we could define a package private one, but >> based on your observation, it may get messier... So I agree that falling >> back

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v16]

2024-07-01 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v15]

2024-06-30 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v14]

2024-06-27 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v12]

2024-06-27 Thread lingjun-cg
On Thu, 27 Jun 2024 05:08:06 GMT, Justin Lu wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > src/java.base/share/classes/j

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v13]

2024-06-27 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v8]

2024-06-26 Thread lingjun-cg
On Tue, 25 Jun 2024 19:33:02 GMT, Naoto Sato wrote: > > So, considering all the information given, is it enough to start our new > > review process? @naotoj @liach @justin-curtis-lu > > Well, I was suggesting the same buffer proxying for other Format classes than > NumberFormat subclasses, suc

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v12]

2024-06-26 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v11]

2024-06-24 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v8]

2024-06-24 Thread lingjun-cg
On Thu, 20 Jun 2024 18:58:27 GMT, Naoto Sato wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > I did not mean to introduce a

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v10]

2024-06-21 Thread lingjun-cg
On Fri, 21 Jun 2024 07:25:27 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic >> instructions. But when run with JDK 11, there is no such problem. The >> reason is th

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v10]

2024-06-21 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v9]

2024-06-21 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v8]

2024-06-20 Thread lingjun-cg
On Thu, 20 Jun 2024 21:53:25 GMT, Justin Lu wrote: > > It requires append(int), but the Appendable has no such method. > > If via `Appendable` we don't have access to `append(int)`, can we simply > `append(String.valueOf(int))`. And similarly for `append(char[], int, int)`, > can we `append(St

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v8]

2024-06-19 Thread lingjun-cg
On Tue, 18 Jun 2024 10:00:33 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic >> instructions. But when run with JDK 11, there is no such problem. The >> reason is th

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v8]

2024-06-18 Thread lingjun-cg
On Wed, 19 Jun 2024 02:12:01 GMT, lingjun-cg wrote: >> src/java.base/share/classes/java/text/Format.java line 278: >> >>> 276: * {@code false} otherwise >>> 277: */ >>> 278: boolean isInternalSubclass() { >> >> Since this

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v8]

2024-06-18 Thread lingjun-cg
On Tue, 18 Jun 2024 20:39:30 GMT, Justin Lu wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > src/java.base/share/classes/ja

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v8]

2024-06-18 Thread lingjun-cg
On Tue, 18 Jun 2024 20:36:52 GMT, Justin Lu wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > src/java.base/share/classes/

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v8]

2024-06-18 Thread lingjun-cg
On Tue, 18 Jun 2024 10:00:33 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic >> instructions. But when run with JDK 11, there is no such problem. The >> reason is th

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v5]

2024-06-18 Thread lingjun-cg
ow about using >>> something as simple as "StringBuf"? >> >> Thanks for your comment. The long name bother me for a while. I have changed >> it to ""StringBuf". > > Hi @lingjun-cg > > Thanks for your work here. > > While t

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v8]

2024-06-18 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Withdrawn: 8333396: Performance regression of DecimalFormat.format

2024-06-17 Thread lingjun-cg
On Mon, 3 Jun 2024 04:18:20 GMT, lingjun-cg wrote: > ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic > instructions. But when run with JDK 11, there is no such problem. The reason > is the removed bi

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v7]

2024-06-17 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 50 3

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v5]

2024-06-13 Thread lingjun-cg
On Thu, 13 Jun 2024 17:53:45 GMT, Justin Lu wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > src/java.base/share/classes/java

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v5]

2024-06-13 Thread lingjun-cg
On Thu, 13 Jun 2024 19:40:49 GMT, Chen Liang wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > src/jav

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v5]

2024-06-13 Thread lingjun-cg
On Thu, 13 Jun 2024 19:40:48 GMT, Naoto Sato wrote: > I second Justin's suggestion here. The change should benefit every > implementation in the JDK, not only NumberFormat. Also, I might suggest > renaming the new class, as it is kind of long/redundant. How about using > something as simple as

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v6]

2024-06-13 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v4]

2024-06-12 Thread lingjun-cg
On Tue, 4 Jun 2024 19:44:57 GMT, Naoto Sato wrote: >> lingjun-cg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 896: Performance regression of DecimalFormat.format > > Also it would be helpful to c

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v5]

2024-06-04 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v4]

2024-06-04 Thread lingjun-cg
On Tue, 4 Jun 2024 19:44:57 GMT, Naoto Sato wrote: > Also it would be helpful to compare the performance without biased locking in > JDK11. If run in JDK11 without biased locking, the performance is as same as run in current JDK. - PR Comment: https://git.openjdk.org/jdk/pull/195

Integrated: 8333462: Performance regression of new DecimalFormat() when compare to jdk11

2024-06-04 Thread lingjun-cg
On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg wrote: > Run the below benchmark test ,it show the average time of new > DecimalFormat() increase 18% when compare to jdk 11. > > the result with jdk 11: > > Benchmark Mode CntSc

Re: RFR: 8333462: Performance regression of new DecimalFormat() when compare to jdk11 [v2]

2024-06-04 Thread lingjun-cg
icant time. > After replacing the lambda implementation with a simple loop , it shows > nearly the same performance as jdk 11. > > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v4]

2024-06-04 Thread lingjun-cg
DecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 5

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v3]

2024-06-04 Thread lingjun-cg
On Tue, 4 Jun 2024 07:54:56 GMT, kuaiwei wrote: > > > Hi, I think you can add the jmh test case. > > > > > > [#19513 > > (comment)](https://github.com/openjdk/jdk/pull/19513#issue-2330131051) > > already contains the test case. > > I mean it can be added as a test case in test/micro and be e

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v3]

2024-06-04 Thread lingjun-cg
On Tue, 4 Jun 2024 07:21:15 GMT, kuaiwei wrote: > Hi, I think you can add the jmh test case. https://github.com/openjdk/jdk/pull/19513#issue-2330131051 already contains the test case. - PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2146844849

RFR: 8333462: Performance regression of new DecimalFormat() when compare to jdk11

2024-06-03 Thread lingjun-cg
Run the below benchmark test ,it show the average time of new DecimalFormat() increase 18% when compare to jdk 11. the result with jdk 11: Benchmark Mode CntScore Error Units JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op the result with

Re: RFR: 8333396: Performance regression of DecimalFormat.format [v3]

2024-06-03 Thread lingjun-cg
t 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode CntScore Error Units > JmhDecimalFormat.testFormatOnlyavgt 50 364.214 ? 1.191 ns/op > Jmh

Re: RFR: 8333396: Performance regression of new DecimalFormat and DecimalFormat.format [v2]

2024-06-03 Thread lingjun-cg
On Mon, 3 Jun 2024 06:13:35 GMT, lingjun-cg wrote: >> ### Performance regression of DecimalFormat.format >> From the output of perf, we can see the hottest regions contain atomic >> instructions. But when run with JDK 11, there is no such problem. The >> reason is th

Re: RFR: 8333396: Performance regression of new DecimalFormat and DecimalFormat.format [v2]

2024-06-02 Thread lingjun-cg
s/op > JmhDecimalFormat.testNewAndFormat avgt 50 615.145 ? 2.478 ns/op > JmhDecimalFormat.testNewOnly avgt 50 209.874 ? 9.951 ns/op > > > ### JDK 11 > > Benchmark Mode Cnt Score Error Units > JmhDecimalFormat.testFormatOnly

RFR: 8333396: Performance regression of new DecimalFormat and DecimalFormat.format

2024-06-02 Thread lingjun-cg
### Performance regression of DecimalFormat.format >From the output of perf, we can see the hottest regions contain atomic >instructions. But when run with JDK 11, there is no such problem. The reason >is the removed biased locking. The DecimalFormat uses StringBuffer everywhere, and StringBuf