Re: [PATCH] AbstractStringBuilder.append()

I think adding a dedicated method would help clarify and encourage performant code. For example, I sped up the snippet below after seeing that StringBuilder.append() has a fast path when the arg is another StringBuilder, which isn't clear from the javadoc. public class ScalaSB implements

[RFC] StringBuilder.toCharArray

Is there any interest in a toCharArray method for StringBuilder? I'm unable to to make a bug for it. Just a bit of sugar: char[] toCharArray() { int length = length(); char[] dst = new char[length]; getChars(0, length, dst, 0); return dst; } Regards, Isaac

Re: [PATCH] regex matcher opt: remove redundant StringBuilder

I still think it would be valuable to land a patch for replaceAll to avoid temporary StringBuilders, is there anyone who wants to help me land it? Isaac On Sun, Apr 29, 2018 at 10:24 PM, Isaac Levy wrote: > Your patch looks good to me, and will get the majority of performance > be

Re: [PATCH] AbstractStringBuilder.append()

it's a concern now. > > (I don’t think there is any circularity that would result from bridge methods > if such a method was added.) > > Paul. > >> On Jun 27, 2018, at 10:22 PM, Martin Buchholz wrote: >> >> I'm fairly sure the append(StringBuilder) overloads

Re: [PATCH] AbstractStringBuilder.append()

And can't remove append(StringBuffer) because of binary compatibility? Isaac On Thu, Jun 28, 2018 at 1:22 AM, Martin Buchholz wrote: > I'm fairly sure the append(StringBuilder) overloads were left out > intentionally. > > On Wed, Jun 27, 2018 at 8:57 PM, Isaac

[PATCH] AbstractStringBuilder.append()

AbstractStringBuilder already has append(). This patch adds append(). The new method improves parity between the two classes. In addition, combining StringBuilders is presumably common. append() has a couple insteadof checks, which this new method skips. -Isaac diff --git

Re: [PATCH] regex matcher opt: remove redundant StringBuilder

penjdk.java.net/~sherman/regex_removesb/webrev/ > > > On 4/24/18, 10:47 AM, Isaac Levy wrote: >> >> Hi Sherman, >> >> Thanks for clarifying. Looks like exceptions are caused by invalid >> format string. I wouldn't expect most programs to be catching this and

Re: [PATCH] regex matcher opt: remove redundant StringBuilder

ing based replaceAll/First() it might be worth doing something like > > http://cr.openjdk.java.net/~sherman/regex_removesb/webrev/ > > > On 4/24/18, 10:47 AM, Isaac Levy wrote: >> >> Hi Sherman, >> >> Thanks for clarifying. Looks like exceptions are caused by invalid &

Re: [PATCH] regex matcher opt: remove redundant StringBuilder

ecified explicitly in the API doc. The newly added > StringBuilder variant simply follows this behavior. If it's really desired > it > is kinda doable to save that StringBuilder without the "incompatible" > behavior > change but just wonder if it is really worth the effo

[PATCH] regex matcher opt: remove redundant StringBuilder

(moving this to a separate discussion) --- a/src/java.base/share/classes/java/util/regex/Matcher.java +++ b/src/java.base/share/classes/java/util/regex/Matcher.java @@ -993,13 +993,11 @@ public Matcher appendReplacement(StringBuilder sb, String replacement) { // If no match, return

Re: [PATCH] minor regex cleanup: use switch for enum

On Mon, Apr 23, 2018 at 5:05 PM Xueming Shen wrote: > > I would assume in case of an exception thrown from > appendExpandedReplacement() we don't > want "text" to be pushed into the "sb". > > -sherman > Perhaps. Though the behavior under exception is undefined and this

Re: [PATCH] minor regex cleanup: use switch for enum

On Mon, Apr 23, 2018 at 5:18 PM David Lloyd wrote: > FWIW I strongly doubt this will improve performance; probably the > opposite in fact, as IIRC an enum switch generates an extra class > (though perhaps this has changed). The original code was quite > compact and

Re: [PATCH] minor regex cleanup: use switch for enum

Thanks. Another small perf patch below -- maybe we can combine. Avoids a StringBuilder allocation: --- a/src/java.base/share/classes/java/util/regex/Matcher.java +++ b/src/java.base/share/classes/java/util/regex/Matcher.java @@ -993,13 +993,11 @@ public Matcher appendReplacement(StringBuilder

Re: [PATCH] minor regex cleanup: use switch for enum

ping? Isaac On Wed, Apr 18, 2018 at 2:58 PM, Isaac Levy <isaac.r.l...@gmail.com> wrote: > Hi, > > Minor improvement in readability (and probably perf) for Pattern. Switch > is more consistent with the rest of the impl and the resulting tableswitch > avoids a compa

[PATCH] minor regex cleanup: use switch for enum

Hi, Minor improvement in readability (and probably perf) for Pattern. Switch is more consistent with the rest of the impl and the resulting tableswitch avoids a comparison for possessives. -Isaac --- a/src/java.base/share/classes/java/util/regex/Pattern.java +++

Re: Long.bitCount micro-optimization

On Mon, May 8, 2017 at 10:54 PM Martin Buchholz wrote: > > Being able to do better here is very impressive. > > I took a quick look and found two things that a paranoid benchmarker like > myself would not have done: > - write the benchmark in scala instead of boring java > -

Re: Long.bitCount micro-optimization

jmh:run -t1 -f 1 -wi 5 -i 10 BitCountTest bitCountInt avgt 10 44550.630 ± 2670.294 ns/op bitCountIntNew avgt 10 33904.058 ± 1108.438 ns/op bitCountLong avgt 10 58638.138 ± 3736.014 ns/op bitCountLongNew avgt 10 38700.601 ± 526.648 ns/op JDK 1.8.0_131, 2.3ghz Core

Re: Long.bitCount micro-optimization

m/techdocs/25112.pdf), an official AMD optimization guide. Isaac On Mon, May 8, 2017 at 4:29 PM, Doug Lea <d...@cs.oswego.edu> wrote: > On 05/08/2017 02:14 PM, Isaac Levy wrote: >> >> Original message below: >> >> The JDK impl of bitCount can be improved -- though m

Re: Long.bitCount micro-optimization

Original message below: The JDK impl of bitCount can be improved -- though most users will get the hotspot intrinsic. The best source I could find for the suggestion below is page 195: http://support.amd.com/techdocs/25112.pdf Cheers, Isaac Levy Proposed Long.bitCount and Integer.bitCount