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

[Peter Levart]

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