Similar suggestion has been on the to-do list for a while. There were
discussion back
then that it might be interesting to add the more general interface
Appendable...
The issue was how to deal with the IOE declared by the Appendable methods then.
If the appendable is not going to happen, then it is definitely worth adding
the StringBuilder
for better performance.
-Sherman
On 03/19/2014 10:51 AM, 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
On Wed, Mar 19, 2014 at 10:41 AM, Jeremy Manson<jeremyman...@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
