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.reinh...@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
