Worth having a StringBuilder for 5 concatenations? [duplicate]

This question already has answers here: Closed 12 years ago.

Possible Duplicate:

At what point does using a StringBuilder become insignificant or an overhead?

Related/Duplicate Questions

String vs StringBuilder

At what point does using a StringBuilder become insignificant or an overhead?

As plain as possible I have this method 1:

cmd2.CommandText = ("insert into " + TableName + " values (" + string.Join(",", insertvalues) + ");");

I am wondering if method 2 be faster if I would do:

StringBuilder sb2 = new StringBuilder();
sb2.Append("insert into ");
sb2.Append(TableName);
sb2.Append(" values (");
sb2.Append(string.Join(",", insertvalues));
sb2.Append(");");

cmd2.Comman开发者_JS百科dText = sb2.ToString();

---

You could also try String.Format, which I believe uses a StringBuilder internally but has increased readability.

cmd2.CommandText = string.Format("insert into {0} values ({1});", TableName, string.Join(",", insertvalues));

(This is for C#)

---

For small programs this will be a premature optimization.

If you want to take into consideration these kinds of optimization then better measure it, because this depends on the size of the string concatenated also, apart from the number or appends.

---

Besides that IMO the StringBuilder method looks and reads better the StringBuilder does outperform string concatenation after 5 to 10 added strings according to http://dotnetperls.com/stringbuilder-performance

---

In C# an expression in the form "a" + b + "c" is optimized by the compiler into String.Concat("a", b, "c") so you will not get intermediary strings. This would be more efficient than a StringBuilder.

---

From here:

The Java language provides special support for the string concatenation operator ( + ), and for conversion of other objects to strings. String concatenation is implemented through the StringBuffer class and its append method.

So it would seem that the compiler is using StringBuffer on your behalf anyway.

---

A good compiler should optimize this for you - but don't take my word for it when you can easily find out for yourself.

Unless you are doing this in a tight loop, then the difference in performance is likely to be insignificant.

String concatenation of values is usually a bad way to construct SQL statements when you could use bind variables instead. This allows the database to optimize the queries. Using bind is likely to make a much bigger difference than optimizing your string construction - and with bind you only need to construct the string once per session instead of once per query.

---

Use String.format.

String.format("insert into {0} values({1});",TableName,string.Join(",", insertvalues));

It's more readable.

---

Your two methods will not differ in performance, the reason is that your string is concatenaled in 1 expression, and the compiler will create a StringBuilder for that expression. The following are equivalent and result in the same code:

String s1 = "five" + '=' + 5;

String s2 = new StringBuilder().append("five").append('=').append(5).toString();

If your code splits up the expresion, for instance in a loop, creating your own StringBuilder will perform better, the naive version using string + concatenation results after compilation in code like:

String s3 = "";

for (int n = 0; n < 5; n++) {

    s3 = new StringBuilder(s3).append(getText(n)).append('=').append(n).append("\n").toString();
}

creating your method using an explicit StringBuilder can save creation of unnecessary StringBuilder objects.

For simple methods you normally do not have to optimise string concatenation yourself, but in those situations where the code is on the critical path, or where you are forced to use many different string expression to build up your end result, it is a good to know what happens under the hood so you can decide whether it is worth the extra effort.

Note that StringBuffer is thread-safe, while StringBuilder is not. StringBuilder is the faster choice for situations where multi-threaded access is not an issue.