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

[Jeremy Manson]

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
>>>
>>>
>