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

[Jeremy Manson]

So, this is all a little opaque to me.  How do we make the go/no-go
decision on something like this?  Everyone who has chimed in seems to think
it is a good idea.

Jeremy


On Thu, Mar 20, 2014 at 10:38 AM, Jeremy Manson <jeremymanson at google.com>wrote:

> Sherman,
>
> If you had released it then (which you wouldn't have been able to do,
> because you would have to wait another two years for Java 7), you would
> have found that it improved performance even with C2.  It is only
> post-escape-analysis that the performance in C2 equalized.
>
> Anyway, I think adding the StringBuilder variant and deferring / dealing
> with the Appendable differently is the right approach, FWIW.
>
> Jeremy
>
>
> On Thu, Mar 20, 2014 at 10:25 AM, Xueming Shen <xueming.shen at oracle.com>wrote:
>
>> 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
>>>>>>
>>>>>>
>>>>>>
>>
>