Re: StringBuffer/StringBuilder efficiency
On Thu, 8 Oct 2009, Roedy Green wrote:
On Thu, 08 Oct 2009 20:56:22 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :
I wrote and posted FastCat, code that saves addresses of Strings, and
concatentate them when you call toString. It needs a new String
constructor to avoid the final copy, but as it is, it does not buy me
anything noticeable over regular StringBuilders with optimised buffer
sizes. I benchmarked it in my app that expands static macros for my
website.
One of the things I did not appreciate, is each chunk requires a
4-byte overhead, If your chunks are only 2 to 4 bytes long, that is
quite a huge percentage.
I did not convert over StringBuffers that were working a char at a
time.
Okay, so maybe we can have a hybrid approach that accumulates large
strings in the list, but when fed short strings or individual characters,
puts them into a buffer - which it then has to push onto the list when the
next large thing comes along, of course.
final static int SMALL_THRESHOLD = 8;
StringBuilder smallStrings;
List<CharSequence> pieces;
void append(String s) {
if (s.length() < SMALL_THRESHOLD) {
if (smallStrings == null) smallStrings = new StringBuilder();
smallStrings.append(s);
}
else {
if (smallStrings != null) {
pieces.add(smallStrings);
smallStrings = null;
}
pieces.add(s);
}
}
You'd want a bit more finesse than this, to avoid ever growing
smallStrings - if it fills up, you want to push it onto pieces and make a
new one. StringBuilder is probably the wrong choice; you could roll a
little FixedSizeStringBuffer thing.
tom
--
King Kong. In Cannes. On a date with Spiderman.