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

[Jeremy Manson]

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