On Mon, 23 Oct 2023 11:50:02 GMT, Shaojin Wen wrote:
> Can I add scale2 method to StringLatin1?
I'd strongly advice against this.
> I think this is more readable than using MethodHandle.
View the `MethodHandle`s you add to use `StringConcatFactory` here as a
temporary workaround before the c
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 single-cha
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 stab
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 single-cha
On Thu, 19 Oct 2023 11:38:57 GMT, Shaojin Wen wrote:
> In addition to #16244, will you submit a PR for this?
Once both #16244 and this has been integrated I want to revisit this. The
effect of changing `getBytes(byte[], int, byte)` might have disappeared with
#16244 since it better guarantees
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 for review - thanks for helping with analysi
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 for review - thanks for helping with analysi
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
>> BigDecimal#StringBuilderHelper, i also
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
>> BigDecimal#StringBuilderHelper, i also
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
>> BigDecimal#StringBuilderHelper, i also
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
>> BigDecimal#StringBuilderHelper, i also
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
>> BigDecimal#StringBuilderHelper, i also
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
>> BigDecimal#StringBuilderHelper, i also
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
>> BigDecimal#StringBuilderHelper, i also
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
>> BigDecimal#StringBuilderHelper, i also
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
>> BigDecimal#StringBuilderHelper, i also
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
>> BigDecimal#StringBuilderHelper, i also
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
>> BigDecimal#StringBuilderHelper, i also
> 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
> BigDecimal#StringBuilderHelper, i also make performance faster.
> Please review and don't hesitate
On Fri, 8 Sep 2023 14:50:15 GMT, Claes Redestad wrote:
> Seems like a step in the right direction w.r.t. code duplication. There's
> still a lot going on in this PR so it'll take some time to digest. Is there
> some way to split this into a series of enhancements for easier review? The
> `jla.
On Fri, 8 Sep 2023 16:25:27 GMT, Roger Riggs wrote:
>> I'll have a look at #14655 though I note that @RogerRiggs has already
>> commented that this might not carry its own weight. These internal API
>> bridges are a nuisance so we need to take care to make sure that any
>> addition is actually
On Fri, 8 Sep 2023 15:48:55 GMT, Claes Redestad wrote:
>> Going from `jla.newStringNoRepl(bytes, ISO_...)` to
>> `jla.newStringLatin1NoRepl(bytes)` isn't much of a code simplification, so
>> this distracts a bit from the bulk of the changes in this PR. I agree that
>> it *might* help inlining
On Fri, 8 Sep 2023 15:48:55 GMT, Claes Redestad wrote:
>> Going from `jla.newStringNoRepl(bytes, ISO_...)` to
>> `jla.newStringLatin1NoRepl(bytes)` isn't much of a code simplification, so
>> this distracts a bit from the bulk of the changes in this PR. I agree that
>> it *might* help inlining
On Fri, 8 Sep 2023 15:41:41 GMT, Claes Redestad wrote:
>> Notice there is patch https://github.com/openjdk/jdk/pull/14655 (bug
>> 8310901) for converting these usages to a new `newStringLatin1NoRepl`.
>
> Going from `jla.newStringNoRepl(bytes, ISO_...)` to
> `jla.newStringLatin1NoRepl(bytes)` i
On Fri, 8 Sep 2023 15:39:47 GMT, Chen Liang wrote:
>> newStringLatin1NoRepl does not significantly help performance, but it
>> simplifies the code.
>>
>> Of course, there is another advantage: because the call will be simpler,
>> making it easier for the caller method to implement codeSize sm
On Fri, 8 Sep 2023 15:34:16 GMT, 温绍锦 wrote:
>> src/java.base/share/classes/java/lang/String.java line 699:
>>
>>> 697: }
>>> 698:
>>> 699: static String newStringLatin1NoRepl(byte[] bytes) {
>>
>> How much does this help compared to calling `jla.newStringNoRepl(bytes,
>> StandardChars
On Fri, 8 Sep 2023 12:25:02 GMT, Claes Redestad wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Continue to optimize and reduce duplicate code
>
> src/java.base/share/classes/java/lang/String.java line 699:
>
>> 697: }
On Fri, 8 Sep 2023 12:00:17 GMT, 温绍锦 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
>> allocations, I made a
> 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
> allocations, I made a modification to improve performance.
>
> Because
30 matches
Mail list logo
