Unexpectedly unknown basic tips about StringBuilder [Java / C #]

How to initialize while keeping an instance of StringBuilder alive

I use RingBuilder to speed up string concatenation, but I'm sure there are times when I want to reuse instances.

For example, this is the implementation code.

• (Actually, it is more realistic to edit a little and make a string, edit a little and make a string, etc. several times instead of loop processing. It's long to write as sample code, so I'll substitute it with loop processing!) *

Code example (C#）

StringBuilder sb;

foreach( var x in data )
{
    sb = new StringBuilder();
    
    //Processing to edit a character string
    
    string text = sb.ToString();
}

Code example (Java)

StringBuilder sb;

for ( Object x : data ) {
    sb = new StringBuilder();
    
    //Processing to edit a character string
    
    String text = sb.toString();
}

In short, it's a case of recreating an instance for the purpose of clearing the edit string.

I think it's a code you often see.

However, the editing process itself is not very heavy, and in cases where the cost of creating an instance of StringBuilder is higher, you will want to reuse the instance.

How to clear StringBuilder

So, as for the title "Unexpectedly unknown", StringBuilder provides a means to clear the internal character buffer * (← slightly misleading explanation) * while keeping the instance alive.

Code example (C#）

var sb = new StringBuilder(); 

foreach( var x in data )
{
    sb.Length = 0; //This clears the previously edited string and allows you to start a new edit.
    
    //Processing to edit a character string
    
    string text = sb.ToString();
}

Code example (Java)

StringBuilder sb = new StringBuilder();

for ( Object x : data ) {
    sb.setLength(0);
    
    //Processing to edit a character string
    
    String text = sb.toString();
}

• • If you aim for speed, it is better to specify the initial buffer in anticipation of the approximate edit size. Just specifying this will change it quite a bit. *
• • There is another way to do it, but I don't like it unless I add an extension method (in C #) so that it can be called simply because that code is messy and difficult to understand. I don't like the API of specifying the number of characters to be deleted one by one. .. .. *

To be honest, when I first learned about this method, I thought ** "I wish I had prepared the StringBuilder.Clear () method instead!" **.

Well, the number of Clear methods has increased.

C#: https://msdn.microsoft.com/ja-jp/library/system.text.stringbuilder.clear(v=vs.110).aspx

• • If the version has not changed and the internal implementation has not changed, they are just doing the process of "setting 0 to the Length property" internally. *

Java: I looked it up, but Java didn't have more clear methods. Will it increase with Java 9? ??

• • Instead, I've heard rumors that Java 9 replaces the compilation result of the "+" operator with a faster implementation than StringBuilder. *

Supplementary explanation @Java

In Java, the "+" operator for string concatenation (which seems to be from some older version) is now compiled to generate bytecode using StringBuilder.

I entered Java from the Java 7 era (when I was excited to hear that lambda was added in Java 8), so I didn't know it at all until I researched it. Other than that, the internal implementation of substring has changed, and it seems that there have been various changes due to its long history (than C #), so it's interesting to investigate that area as well.

Code implemented with the plus operator

String a = "That's right,";
String b = "we";
String c = "Because it's smart."
String text = a + b + c; //Yes, because we are smart.

Code equivalent to the compilation result

String a = "That's right,";
String b = "we";
String c = "Because it's smart."
String text = new StringBuilder().append( a ).append( b ).append( c ).toString(); //Yes, because we are smart.

• • Of course, I ignored compiler optimization such as constant expansion! !! *

Precautions and other things that come after.

** Don't make StringBuilder too long: **

Although there are ways to clear it, StringBuilder is an edit buffer in the first place and shouldn't have a very long lifespan. Above all, there is no such thing as how many times or tens of times the processing speed can be increased by using this clearing means.

Don't overdo it.

** It's just an "editing area", a buffer: **

The stance that StringBuilder is only a buffer area in the middle of editing should not be changed, Reusing an instance, clearing it, and using it should be suppressed at best by "a level that is completed within the process that starts with a single public method".

• (I usually follow that kind of guideline. It would be awkward if I was promoted because my survival time was too long in the GC ...) *

Another important criterion is whether the code "new StringBuilder ();" is too loud as noise. If this is too noticeable compared to the short and simple main logic, I think it would be better if you could write "sb.Clear ();" to make the code more intuitive.

** Thinking about the Length property: **

Also, personally, it is not intuitive in the first place that "a value can be set for Length, which is a property that obtains the number of characters as a result of editing a character string", and this is provided as a clearing means. I wondered what it was like. Length is read-only, and I think that the Clear method should be provided as a means of clearing.

• (C # has been added, so I wonder if Java will be added too) *

Well, it's good because I rarely do "building up character strings in a mess" these days.

• (It's still a long time ago when strings were messed up ...) *