StringBuilder version of java.util.regex.Matcher.append* (original) (raw)

Xueming Shen xueming.shen at oracle.com
Thu Mar 20 17:25:03 UTC 2014

2009? I do have something similar back to 2009 :-)

http://cr.openjdk.java.net/~sherman/regex_replace/webrev/

Then the ball was dropped around the discussion of whether or not the IOE should be thrown.

But if we are going to/have to have explicit StringBuilder/Buffer pair anyway, then we can keep the Appendable version as private for now and deal with the StringBuilder and Appendable as two separate issues.

-Sherman

On 03/20/2014 09:52 AM, Jeremy Manson wrote:

That's definitely an improvement - I think that when I wrote this (circa 2009), I didn't think about Appendable.

I take it my argument convinced someone? :) Jeremy

On Thu, Mar 20, 2014 at 1:32 AM, Peter Levart<peter.levart at gmail.com>wrote: On 03/19/2014 06:51 PM, Jeremy Manson wrote:

I'm told that the diff didn't make it. I've put it in a Google drive folder...

https://drive.google.com/file/d/0BGaXa6O4K5LY3Y0aHpranM3aEU/ edit?usp=sharing Jeremy Hi Jeremy, Your factoring-out of expandReplacement() method exposed an opportunity to further optimize the code. Instead of creating intermediate StringBuilder instance for each expandReplacement() call, this method could append directly to resulting StringBuffer/StringBuilder, like in the following: http://cr.openjdk.java.net/~plevart/jdk9-dev/MatcherWithStringBuilder/ webrev.01/ Regards, Peter

On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson<jeremymanson at google.com> wrote: Hi folks, We've had this internally for a while, and I keep meaning to bring it up here. The Matcher class has a few public methods that take StringBuffers, and we've found it useful to add similar versions that take StringBuilders. It has two benefits: - Users don't have to convert from one to the other when they want to use the method in question. The symmetry is nice. - The StringBuilder variants are faster (if lock optimizations don't kick in, which happens in the interpreter and the client compiler). For interpreted / client-compiled code, we saw something like a 25% speedup on String.replaceAll(), which calls into this code. Any interest? Diff attached. Jeremy

More information about the core-libs-dev mailing list