Beating StringBuilder? Hell no.

So, it turns out that StringBuilder is almost insultingly fast. It’s very well written, does almost no allocation, and is almost certainly getting special help from the VM and JIT under the covers. Appending a medium sized string to it appears to be faster (when averaged over about 11000 appends) than allocating new objects!

I’m almost tempted to try writing a mutable JumpRopeBuilder which does the same job to see if I can beat it (and I probably will anyway, but use it to generate balanced JumpRopes rather than optimise it for appends), but I think I’ll restrain myself. I must remember that hte goal is to have a String replacement rather than a StringBuilder replacement, and as that this does pretty well – the appends are very fast compared to String append (the actual conversion to a string is a little slow admittedly – it takes 100-200 ms for a approximately 100k characters, and about half of that is the overhead of iterating over an unbalanced binary tree). And, unlike StringBuilder, this is totally thread safe by virtue of being immutable.

Which reminds me, I should compare it against StringBuffer.

Anyway, I should really start adding some actual functionality now. :-)

This entry was posted in programming and tagged , , , on by .

3 thoughts on “Beating StringBuilder? Hell no.

  1. Wilf

    There is already a replacement for String that is much much faster with all the concatenations, etc.

    See the Text class at http://www.javolution.com, “JavolutionJava library for real-Time, embedded and high-performance applications.”

    The only problem is that it does not support the ‘+’ operator.

  2. David R. MacIver

    That’s very interesting. Thanks. I did a search when I originally created this, but I couldn’t find anything.

    I’ll probably continue with mine, as it’s fun to write and generating a lot of interesting byproducts, but the javolution code is almost certainly more suitable for production usage and likely to remain so. :-)

  3. David R. MacIver

    On further investigation, another reason to continue with mine is different priorities. The javolution implementation is very good, but there are a number of cases where it looks like they’ve traded potentially better (amortized) complexities for real time guarantees. There’s definitely a case to be made for that, but it’s not what I’m trying for.

Comments are closed.