8058779: Faster implementation of String.replace(CharSequence, CharSequence)

[Tomasz Kowalczewski]

I second that. API accepts CharSequence for a reason. The benchmarks might
look a little different if you pass StringBuilder in a call to replace. It
looks like removing toString() call on CharSequences will be easy with one
drawback of loosing the benefit of System.arraycopy call. Note that
String.indexOf requires String argument but that can also be fixed.

--
Tomasz

On Tue, May 26, 2015 at 7:17 PM, Xueming Shen <xueming.shen at oracle.com>
wrote:

> On 5/26/15 10:08 AM, Ivan Gerasimov wrote:
>
>> Thank you Roger for looking at this!
>>
>> On 26.05.2015 19:40, Roger Riggs wrote:
>>
>>> Hi Ivan,
>>>
>>> Did you consider doing the optimization inside of
>>> Pattern.compile/replaceAll.
>>> That would have a broader impact and benefit.
>>>
>>>
>> In Pattern.compile the flag LITERAL can be combined with several other
>> flags, which makes things more complex.
>> However, in String.replace we've got a special case, which can be
>> optimized in a straight-forward (though a little bit verbose) way.
>>
>
> It probably makes big difference to access those characters via
> CharSequence.charAt()
> and the direct internal char[] access. Though avoiding allocating those
> objects created
> by Pattern/Matcher/SB definitely helps.
>
> -Sherman
>
>
>
>> Sincerely yours,
>> Ivan
>>
>>  Roger
>>>
>>>
>>> On 5/26/2015 12:36 PM, Ivan Gerasimov wrote:
>>>
>>>> Thank you Mark for looking at this!
>>>>
>>>> On 26.05.2015 18:39, mark.reinhold at oracle.com wrote:
>>>>
>>>>> Your micro-benchmark improvements are significant, but do you have
>>>>> evidence to suggest that the performance of this method is actually
>>>>> critical to real applications?
>>>>>
>>>>> In other words, is the added code complexity really worth it?
>>>>>
>>>>
>>>> The enhancement request contains a few links to the discussions of this
>>>> method's performance at open forums.
>>>> The most frequent suggestion is to use alternatives from 3rd party
>>>> libraries.
>>>>
>>>> That should prove the benefits of this fix -- by improving performance
>>>> we can keep some users from moving away from JDK :)
>>>>
>>>> grep shows that langtools would also benefit from making replace()
>>>> faster.
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>>  - Mark
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>


-- 
Tomasz Kowalczewski