Re: RFR: 8347009: Speed ​​up parseInt and parseLong [v4]

2025-01-04 Thread j3graham
On Sun, 5 Jan 2025 07:07:15 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, >> which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance >> improvements

Re: RFR: 8347009: Speed ​​up parseInt and parseLong [v3]

2025-01-04 Thread j3graham
On Sun, 5 Jan 2025 00:12:03 GMT, Shaojin Wen wrote: > 2. The leading zero scenario is not common, and there is no need to optimize > this scenario. Another approach would be to limit the “fast” path to the case where the overall string length is 9 or less. That would allow overflow-free calcu

Re: RFR: 8347009: Speed ​​up parseInt and parseLong [v3]

2025-01-04 Thread j3graham
On Sat, 4 Jan 2025 12:09:04 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, >> which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance >> improvements

Re: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v3]

2024-12-15 Thread j3graham
On Fri, 13 Dec 2024 16:06:53 GMT, Raffaello Giulietti wrote: >> See the JBS bug for some details. > > Raffaello Giulietti 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. Th

Re: RFR: 8342650: Move getChars to DecimalDigits

2024-10-20 Thread j3graham
On Sun, 20 Oct 2024 00:19:25 GMT, Shaojin Wen wrote: > Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to > reduce duplication > > 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 > 2. Putting these two methods into DecimalDigits can avoid the ne

Re: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]

2024-10-13 Thread j3graham
On Sun, 13 Oct 2024 17:48:15 GMT, j3graham wrote: >> src/java.base/share/classes/java/math/BigDecimal.java line 5234: >> >>> 5232: */ >>> 5233: private static BigInteger fiveToTwoToThe(int n) { >>> 5234: int i = Math.min(n, FIVE_TO_

Re: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]

2024-10-13 Thread j3graham
On Sun, 13 Oct 2024 14:39:32 GMT, j3graham wrote: >> fabioromano1 has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Minor change > > src/java.base/share/classes/java/math/BigDecimal.java line 5234: > >

Re: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]

2024-10-13 Thread j3graham
On Sat, 12 Oct 2024 17:37:25 GMT, fabioromano1 wrote: >> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses >> repeated squares trick. > > fabioromano1 has updated the pull request incrementally with one additional > commit since the last revision: > > Minor change src/j

Re: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v4]

2023-02-02 Thread j3graham
On Wed, 1 Feb 2023 11:37:16 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/time/ZoneOffset.java line 147: >> >>> 145: >>> 146: /** Cache of time-zone offset by offset in seconds [-18h, +18h] >>> for each even quarter of an hour. */ >>> 147: private static final AtomicRefer

Re: RFR: 8301220: Return value of toArray() of Сollection types from java.base should be trusted [v2]

2023-01-27 Thread j3graham
On Fri, 27 Jan 2023 13:53:45 GMT, Glavo wrote: >> I checked the `java.base` module, and all the `Collection#toArray()` method >> of collections be implemented correctly. >> >> Their return values can be trusted, so many unnecessary array duplication >> can be eliminated. > > Glavo has updated

Re: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]

2023-01-16 Thread j3graham
On Wed, 4 Jan 2023 13:16:26 GMT, Andriy Plokhotnyuk wrote: > > Do you see any concrete examples of classes in the JDK that could benefit > from a "VarHandlization"? `ImageOutputStreamImpl` and `ImageInputStreamImpl` in `javax.imageio.stream` have some very similar code that might benefit.

Re: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v4]

2022-10-28 Thread j3graham
On Fri, 28 Oct 2022 19:51:49 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are >> similar to string literals but contain embedded expressions. A string >> template is interpreted at run time by replacing each expression with the >> result of evalu

Re: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v2]

2022-10-28 Thread j3graham
On Fri, 28 Oct 2022 14:55:28 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are >> similar to string literals but contain embedded expressions. A string >> template is interpreted at run time by replacing each expression with the >> result of evalu

Re: RFR: JDK-8277095 : Empty streams create too many objects [v2]

2022-07-21 Thread j3graham
On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote: >> This is a draft proposal for how we could improve stream performance for the >> case where the streams are empty. Empty collections are common-place. If we >> iterate over them with an Iterator, we would have to create one small >> Iterator ob

Re: RFR: JDK-8277095 : Empty streams create too many objects [v2]

2022-07-16 Thread j3graham
On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote: >> This is a draft proposal for how we could improve stream performance for the >> case where the streams are empty. Empty collections are common-place. If we >> iterate over them with an Iterator, we would have to create one small >> Iterator ob

Re: RFR: JDK-8277095 : Empty streams create too many objects [v2]

2022-07-16 Thread j3graham
On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote: >> This is a draft proposal for how we could improve stream performance for the >> case where the streams are empty. Empty collections are common-place. If we >> iterate over them with an Iterator, we would have to create one small >> Iterator ob