StringBuilder version of java.util.regex.Matcher.append*

[Xueming Shen]

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/0B_GaXa6O4K5LY3Y0aHpranM3aEU/
>>> 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
>>>>
>>>>