I understand the difference between String and StringBuilder (StringBuilder being mutable) but is there a large performance difference between the two?
The program I’m working on has a lot of case driven string appends (500+). Is using StringBuilder a better choice?
This question is related to
c#
.net
performance
The answer is
The performance of a concatenation operation for a String or StringBuilder object depends on how often a memory allocation occurs. A String concatenation operation always allocates memory, whereas a StringBuilder concatenation operation only allocates memory if the StringBuilder object buffer is too small to accommodate the new data. Consequently, the String class is preferable for a concatenation operation if a fixed number of String objects are concatenated. In that case, the individual concatenation operations might even be combined into a single operation by the compiler. A StringBuilder object is preferable for a concatenation operation if an arbitrary number of strings are concatenated; for example, if a loop concatenates a random number of strings of user input.
Source: MSDN
In .NET, StringBuilder is still faster than appending strings. I'm pretty sure that in Java, they just create a StringBuffer under the hood when you append strings, so there's isn't really a difference. I'm not sure why they haven't done this in .NET yet.
This benchmark shows that regular concatenation is faster when combining 3 or fewer strings.
http://www.chinhdo.com/20070224/stringbuilder-is-not-always-faster/
StringBuilder can make a very significant improvement in memory usage, especially in your case of adding 500 strings together.
Consider the following example:
string buffer = "The numbers are: ";
for( int i = 0; i < 5; i++)
{
buffer += i.ToString();
}
return buffer;
What happens in memory? The following strings are created:
1 - "The numbers are: "
2 - "0"
3 - "The numbers are: 0"
4 - "1"
5 - "The numbers are: 01"
6 - "2"
7 - "The numbers are: 012"
8 - "3"
9 - "The numbers are: 0123"
10 - "4"
11 - "The numbers are: 01234"
12 - "5"
13 - "The numbers are: 012345"
By adding those five numbers to the end of the string we created 13 string objects! And 12 of them were useless! Wow!
StringBuilder fixes this problem. It is not a "mutable string" as we often hear (all strings in .NET are immutable). It works by keeping an internal buffer, an array of char. Calling Append() or AppendLine() adds the string to the empty space at the end of the char array; if the array is too small, it creates a new, larger array, and copies the buffer there. So in the example above, StringBuilder might only need a single array to contain all 5 additions to the string-- depending on the size of its buffer. You can tell StringBuilder how big its buffer should be in the constructor.
StringBuilder reduces the number of allocations and assignments, at a cost of extra memory used. Used properly, it can completely remove the need for the compiler to allocate larger and larger strings over and over until the result is found.
string result = "";
for(int i = 0; i != N; ++i)
{
result = result + i.ToString(); // allocates a new string, then assigns it to result, which gets repeated N times
}
vs.
String result;
StringBuilder sb = new StringBuilder(10000); // create a buffer of 10k
for(int i = 0; i != N; ++i)
{
sb.Append(i.ToString()); // fill the buffer, resizing if it overflows the buffer
}
result = sb.ToString(); // assigns once
String concatenation will cost you more. In Java, You can use either StringBuffer or StringBuilder based on your need. If you want a synchronized, and thread safe implementation, go for StringBuffer. This will be faster than the String concatenation.
If you do not need synchronized or Thread safe implementation, go for StringBuilder. This will be faster than String concatenation and also faster than StringBuffer as their is no synchorization overhead.
StringBuilder is better for building up a string from many non-constant values.
If you're building up a string from a lot of constant values, such as multiple lines of values in an HTML or XML document or other chunks of text, you can get away with just appending to the same string, because almost all compilers do "constant folding", a process of reducing the parse tree when you have a bunch of constant manipulation (it's also used when you write something like int minutesPerYear = 24 * 365 * 60). And for simple cases with non-constant values appended to each other, the .NET compiler will reduce your code to something similar to what StringBuilder does.
But when your append can't be reduced to something simpler by the compiler, you'll want a StringBuilder. As fizch points out, that's more likely to happen inside of a loop.
Further to the previous answers, the first thing I always do when thinking of issues like this is to create a small test application. Inside this app, perform some timing test for both scenarios and see for yourself which is quicker.
IMHO, appending 500+ string entries should definitely use StringBuilder.
If you're doing a lot of string concatenation, use a StringBuilder. When you concatenate with a String, you create a new String each time, using up more memory.
Alex
This benchmark shows that regular concatenation is faster when combining 3 or fewer strings.
http://www.chinhdo.com/20070224/stringbuilder-is-not-always-faster/
StringBuilder can make a very significant improvement in memory usage, especially in your case of adding 500 strings together.
Consider the following example:
string buffer = "The numbers are: ";
for( int i = 0; i < 5; i++)
{
buffer += i.ToString();
}
return buffer;
What happens in memory? The following strings are created:
1 - "The numbers are: "
2 - "0"
3 - "The numbers are: 0"
4 - "1"
5 - "The numbers are: 01"
6 - "2"
7 - "The numbers are: 012"
8 - "3"
9 - "The numbers are: 0123"
10 - "4"
11 - "The numbers are: 01234"
12 - "5"
13 - "The numbers are: 012345"
By adding those five numbers to the end of the string we created 13 string objects! And 12 of them were useless! Wow!
StringBuilder fixes this problem. It is not a "mutable string" as we often hear (all strings in .NET are immutable). It works by keeping an internal buffer, an array of char. Calling Append() or AppendLine() adds the string to the empty space at the end of the char array; if the array is too small, it creates a new, larger array, and copies the buffer there. So in the example above, StringBuilder might only need a single array to contain all 5 additions to the string-- depending on the size of its buffer. You can tell StringBuilder how big its buffer should be in the constructor.
StringBuilder is probably preferable. The reason is that it allocates more space than currently needed (you set the number of characters) to leave room for future appends. Then those future appends that fit in the current buffer don't require any memory allocation or garbage collection, which can be expensive. In general, I use StringBuilder for complex string concatentation or multiple formatting, then convert to a normal String when the data is complete, and I want an immutable object again.
StringBuilder will perform better, from a memory stand point. As for processing, the difference in time of execution may be negligible.
StringBuilder is probably preferable. The reason is that it allocates more space than currently needed (you set the number of characters) to leave room for future appends. Then those future appends that fit in the current buffer don't require any memory allocation or garbage collection, which can be expensive. In general, I use StringBuilder for complex string concatentation or multiple formatting, then convert to a normal String when the data is complete, and I want an immutable object again.
In .NET, StringBuilder is still faster than appending strings. I'm pretty sure that in Java, they just create a StringBuffer under the hood when you append strings, so there's isn't really a difference. I'm not sure why they haven't done this in .NET yet.
StringBuilder will perform better, from a memory stand point. As for processing, the difference in time of execution may be negligible.
StringBuilder is preferable IF you are doing multiple loops, or forks in your code pass... however, for PURE performance, if you can get away with a SINGLE string declaration, then that is much more performant.
For example:
string myString = "Some stuff" + var1 + " more stuff"
+ var2 + " other stuff" .... etc... etc...;
is more performant than
StringBuilder sb = new StringBuilder();
sb.Append("Some Stuff");
sb.Append(var1);
sb.Append(" more stuff");
sb.Append(var2);
sb.Append("other stuff");
// etc.. etc.. etc..
In this case, StringBuild could be considered more maintainable, but is not more performant than the single string declaration.
9 times out of 10 though... use the string builder.
On a side note: string + var is also more performant that the string.Format approach (generally) that uses a StringBuilder internally (when in doubt... check reflector!)
A simple example to demonstrate the difference in speed when using String concatenation vs StringBuilder:
System.Diagnostics.Stopwatch time = new Stopwatch();
string test = string.Empty;
time.Start();
for (int i = 0; i < 100000; i++)
{
test += i;
}
time.Stop();
System.Console.WriteLine("Using String concatenation: " + time.ElapsedMilliseconds + " milliseconds");
Result:
Using String concatenation: 15423 milliseconds
StringBuilder test1 = new StringBuilder();
time.Reset();
time.Start();
for (int i = 0; i < 100000; i++)
{
test1.Append(i);
}
time.Stop();
System.Console.WriteLine("Using StringBuilder: " + time.ElapsedMilliseconds + " milliseconds");
Result:
Using StringBuilder: 10 milliseconds
As a result, the first iteration took 15423 ms while the second iteration using StringBuilder took 10 ms.
It looks to me that using StringBuilder is faster, a lot faster.
StringBuilder will perform better, from a memory stand point. As for processing, the difference in time of execution may be negligible.
To clarify what Gillian said about 4 string, if you have something like this:
string a,b,c,d;
a = b + c + d;
then it would be faster using strings and the plus operator. This is because (like Java, as Eric points out), it internally uses StringBuilder automatically (Actually, it uses a primitive that StringBuilder also uses)
However, if what you are doing is closer to:
string a,b,c,d;
a = a + b;
a = a + c;
a = a + d;
Then you need to explicitly use a StringBuilder. .Net doesn't automatically create a StringBuilder here, because it would be pointless. At the end of each line, "a" has to be an (immutable) string, so it would have to create and dispose a StringBuilder on each line. For speed, you'd need to use the same StringBuilder until you're done building:
string a,b,c,d;
StringBuilder e = new StringBuilder();
e.Append(b);
e.Append(c);
e.Append(d);
a = e.ToString();
Using strings for concatenation can lead to a runtime complexity on the order of O(n^2).
If you use a StringBuilder, there is a lot less copying of memory that has to be done. With the StringBuilder(int capacity) you can increase performance if you can estimate how large the final String is going to be. Even if you're not precise, you'll probably only have to grow the capacity of StringBuilder a couple of times which can help performance also.
String and StringBuilder are actually both immutable, the StringBuilder has built in buffers which allow its size to be managed more efficiently. When the StringBuilder needs to resize is when it is re-allocated on the heap. By default it is sized to 16 characters, you can set this in the constructor.
eg.
StringBuilder sb = new StringBuilder(50);
String concatenation will cost you more. In Java, You can use either StringBuffer or StringBuilder based on your need. If you want a synchronized, and thread safe implementation, go for StringBuffer. This will be faster than the String concatenation.
If you do not need synchronized or Thread safe implementation, go for StringBuilder. This will be faster than String concatenation and also faster than StringBuffer as their is no synchorization overhead.
String Vs String Builder:
First thing you have to know that In which assembly these two classes lives?
So,
string is present in System namespace.
and
StringBuilder is present in System.Text namespace.
For string declaration:
You have to include the System namespace.
something like this.
Using System;
and
For StringBuilder declaration:
You have to include the System.text namespace.
something like this.
Using System.text;
Now Come the the actual Question.
What is the differene between string & StringBuilder?
The main difference between these two is that:
string is immutable.
and
StringBuilder is mutable.
So Now lets discuss the difference between immutable and mutable
Mutable: : means Changable.
Immutable: : means Not Changable.
For example:
using System;
namespace StringVsStrigBuilder
{
class Program
{
static void Main(string[] args)
{
// String Example
string name = "Rehan";
name = name + "Shah";
name = name + "RS";
name = name + "---";
name = name + "I love to write programs.";
// Now when I run this program this output will be look like this.
// output : "Rehan Shah RS --- I love to write programs."
}
}
}
So in this case we are going to changing same object 5-times.
So the Obvious question is that ! What is actually happen under the hood, when we change the same string 5-times.
This is What Happen when we change the same string 5-times.
let look at the figure.
Explaination:
When we first initialize this variable "name" to "Rehan" i-e string name = "Rehan"
this variable get created on stack "name" and pointing to that "Rehan" value.
after this line is executed: "name = name + "Shah". the reference variable is no longer pointing to that object "Rehan" it now pointing to "Shah" and so on.
So string is immutable meaning that once we create the object in the memory we can't change them.
So when we concatinating the name variable the previous object remains there in the memory and another new string object is get created...
So from the above figure we have five-objects the four-objects are thrown away they are not used at all. They stil remain in memory and they occuy the amount of memory. "Garbage Collector" is responsible for that so clean that resources from the memory.
So in case of string anytime when we manipulate the string over and over again we have some many objects Created ans stay there at in the memory.
So this is the story of string Variable.
Now Let's look at toward StringBuilder Object. For Example:
using System;
using System.Text;
namespace StringVsStrigBuilder
{
class Program
{
static void Main(string[] args)
{
// StringBuilder Example
StringBuilder name = new StringBuilder();
name.Append("Rehan");
name.Append("Shah");
name.Append("RS");
name.Append("---");
name.Append("I love to write programs.");
// Now when I run this program this output will be look like this.
// output : "Rehan Shah Rs --- I love to write programs."
}
}
}
So in this case we are going to changing same object 5-times.
So the Obvious question is that ! What is actually happen under the hood, when we change the same StringBuilder 5-times.
This is What Happen when we change the same StringBuilder 5-times.
let look at the figure.
Explaination: In case of StringBuilder object. you wouldn't get the new object. The same object will be change in memory so even if you change the object et say 10,000 times we will still have only one stringBuilder object.
You don't have alot of garbage objects or non_referenced stringBuilder objects because why it can be change. It is mutable meaning it change over a time?
Differences:
- String is present in System namespace where as Stringbuilder present in System.Text namespace.
- string is immutable where as StringBuilder is mutabe.
My approach has always been to use StringBuilder when concatenating 4 or more strings OR When I don't know how may concatenations are to take place.
The performance of a concatenation operation for a String or StringBuilder object depends on how often a memory allocation occurs. A String concatenation operation always allocates memory, whereas a StringBuilder concatenation operation only allocates memory if the StringBuilder object buffer is too small to accommodate the new data. Consequently, the String class is preferable for a concatenation operation if a fixed number of String objects are concatenated. In that case, the individual concatenation operations might even be combined into a single operation by the compiler. A StringBuilder object is preferable for a concatenation operation if an arbitrary number of strings are concatenated; for example, if a loop concatenates a random number of strings of user input.
Source: MSDN
I believe StringBuilder is faster if you have more than 4 strings you need to append together. Plus it can do some cool things like AppendLine.
If you're doing a lot of string concatenation, use a StringBuilder. When you concatenate with a String, you create a new String each time, using up more memory.
Alex
Consider 'The Sad Tragedy of Micro-Optimization Theater'.
As a general rule of thumb, if I have to set the value of the string more than once, or if there are any appends to the string, then it needs to be a string builder. I have seen applications that I have written in the past before learning about string builders that have had a huge memory foot print that just seems to keep growing and growing. Changing these programs to use the string builder cut down the memory usage significantly. Now I swear by the string builder.
If you're doing a lot of string concatenation, use a StringBuilder. When you concatenate with a String, you create a new String each time, using up more memory.
Alex
Yes, StringBuilder gives better performance while performing repeated operation over a string. It is because all the changes are made to a single instance so it can save a lot of time instead of creating a new instance like String.
String Vs Stringbuilder
String- under
Systemnamespace - immutable (read-only) instance
- performance degrades when continuous change of value occures
- thread safe
- under
StringBuilder(mutable string)- under
System.Textnamespace - mutable instance
- shows better performance since new changes are made to existing instance
- under
Strongly recommend dotnet mob article : String Vs StringBuilder in C#.
Related Stack Overflow question: Mutability of string when string doesn't change in C#?.
I have seen significant performance gains from using the EnsureCapacity(int capacity) method call on an instance of StringBuilder before using it for any string storage. I usually call that on the line of code after instantiation. It has the same effect as if you instantiate the StringBuilder like this:
var sb = new StringBuilder(int capacity);
This call allocates needed memory ahead of time, which causes fewer memory allocations during multiple Append() operations. You have to make an educated guess on how much memory you will need, but for most applications this should not be too difficult. I usually err on the side of a little too much memory (we are talking 1k or so).
To clarify what Gillian said about 4 string, if you have something like this:
string a,b,c,d;
a = b + c + d;
then it would be faster using strings and the plus operator. This is because (like Java, as Eric points out), it internally uses StringBuilder automatically (Actually, it uses a primitive that StringBuilder also uses)
However, if what you are doing is closer to:
string a,b,c,d;
a = a + b;
a = a + c;
a = a + d;
Then you need to explicitly use a StringBuilder. .Net doesn't automatically create a StringBuilder here, because it would be pointless. At the end of each line, "a" has to be an (immutable) string, so it would have to create and dispose a StringBuilder on each line. For speed, you'd need to use the same StringBuilder until you're done building:
string a,b,c,d;
StringBuilder e = new StringBuilder();
e.Append(b);
e.Append(c);
e.Append(d);
a = e.ToString();
StringBuilder reduces the number of allocations and assignments, at a cost of extra memory used. Used properly, it can completely remove the need for the compiler to allocate larger and larger strings over and over until the result is found.
string result = "";
for(int i = 0; i != N; ++i)
{
result = result + i.ToString(); // allocates a new string, then assigns it to result, which gets repeated N times
}
vs.
String result;
StringBuilder sb = new StringBuilder(10000); // create a buffer of 10k
for(int i = 0; i != N; ++i)
{
sb.Append(i.ToString()); // fill the buffer, resizing if it overflows the buffer
}
result = sb.ToString(); // assigns once
A simple example to demonstrate the difference in speed when using String concatenation vs StringBuilder:
System.Diagnostics.Stopwatch time = new Stopwatch();
string test = string.Empty;
time.Start();
for (int i = 0; i < 100000; i++)
{
test += i;
}
time.Stop();
System.Console.WriteLine("Using String concatenation: " + time.ElapsedMilliseconds + " milliseconds");
Result:
Using String concatenation: 15423 milliseconds
StringBuilder test1 = new StringBuilder();
time.Reset();
time.Start();
for (int i = 0; i < 100000; i++)
{
test1.Append(i);
}
time.Stop();
System.Console.WriteLine("Using StringBuilder: " + time.ElapsedMilliseconds + " milliseconds");
Result:
Using StringBuilder: 10 milliseconds
As a result, the first iteration took 15423 ms while the second iteration using StringBuilder took 10 ms.
It looks to me that using StringBuilder is faster, a lot faster.
If you're doing a lot of string concatenation, use a StringBuilder. When you concatenate with a String, you create a new String each time, using up more memory.
Alex
As a general rule of thumb, if I have to set the value of the string more than once, or if there are any appends to the string, then it needs to be a string builder. I have seen applications that I have written in the past before learning about string builders that have had a huge memory foot print that just seems to keep growing and growing. Changing these programs to use the string builder cut down the memory usage significantly. Now I swear by the string builder.
To clarify what Gillian said about 4 string, if you have something like this:
string a,b,c,d;
a = b + c + d;
then it would be faster using strings and the plus operator. This is because (like Java, as Eric points out), it internally uses StringBuilder automatically (Actually, it uses a primitive that StringBuilder also uses)
However, if what you are doing is closer to:
string a,b,c,d;
a = a + b;
a = a + c;
a = a + d;
Then you need to explicitly use a StringBuilder. .Net doesn't automatically create a StringBuilder here, because it would be pointless. At the end of each line, "a" has to be an (immutable) string, so it would have to create and dispose a StringBuilder on each line. For speed, you'd need to use the same StringBuilder until you're done building:
string a,b,c,d;
StringBuilder e = new StringBuilder();
e.Append(b);
e.Append(c);
e.Append(d);
a = e.ToString();
StringBuilder is significantly more efficient but you will not see that performance unless you are doing a large amount of string modification.
Below is a quick chunk of code to give an example of the performance. As you can see you really only start to see a major performance increase when you get into large iterations.
As you can see the 200,000 iterations took 22 seconds while the 1 million iterations using the StringBuilder was almost instant.
string s = string.Empty;
StringBuilder sb = new StringBuilder();
Console.WriteLine("Beginning String + at " + DateTime.Now.ToString());
for (int i = 0; i <= 50000; i++)
{
s = s + 'A';
}
Console.WriteLine("Finished String + at " + DateTime.Now.ToString());
Console.WriteLine();
Console.WriteLine("Beginning String + at " + DateTime.Now.ToString());
for (int i = 0; i <= 200000; i++)
{
s = s + 'A';
}
Console.WriteLine("Finished String + at " + DateTime.Now.ToString());
Console.WriteLine();
Console.WriteLine("Beginning Sb append at " + DateTime.Now.ToString());
for (int i = 0; i <= 1000000; i++)
{
sb.Append("A");
}
Console.WriteLine("Finished Sb append at " + DateTime.Now.ToString());
Console.ReadLine();
Result of the above code:
Beginning String + at 28/01/2013 16:55:40.
Finished String + at 28/01/2013 16:55:40.
Beginning String + at 28/01/2013 16:55:40.
Finished String + at 28/01/2013 16:56:02.
Beginning Sb append at 28/01/2013 16:56:02.
Finished Sb append at 28/01/2013 16:56:02.
String Vs String Builder:
First thing you have to know that In which assembly these two classes lives?
So,
string is present in System namespace.
and
StringBuilder is present in System.Text namespace.
For string declaration:
You have to include the System namespace.
something like this.
Using System;
and
For StringBuilder declaration:
You have to include the System.text namespace.
something like this.
Using System.text;
Now Come the the actual Question.
What is the differene between string & StringBuilder?
The main difference between these two is that:
string is immutable.
and
StringBuilder is mutable.
So Now lets discuss the difference between immutable and mutable
Mutable: : means Changable.
Immutable: : means Not Changable.
For example:
using System;
namespace StringVsStrigBuilder
{
class Program
{
static void Main(string[] args)
{
// String Example
string name = "Rehan";
name = name + "Shah";
name = name + "RS";
name = name + "---";
name = name + "I love to write programs.";
// Now when I run this program this output will be look like this.
// output : "Rehan Shah RS --- I love to write programs."
}
}
}
So in this case we are going to changing same object 5-times.
So the Obvious question is that ! What is actually happen under the hood, when we change the same string 5-times.
This is What Happen when we change the same string 5-times.
let look at the figure.
Explaination:
When we first initialize this variable "name" to "Rehan" i-e string name = "Rehan"
this variable get created on stack "name" and pointing to that "Rehan" value.
after this line is executed: "name = name + "Shah". the reference variable is no longer pointing to that object "Rehan" it now pointing to "Shah" and so on.
So string is immutable meaning that once we create the object in the memory we can't change them.
So when we concatinating the name variable the previous object remains there in the memory and another new string object is get created...
So from the above figure we have five-objects the four-objects are thrown away they are not used at all. They stil remain in memory and they occuy the amount of memory. "Garbage Collector" is responsible for that so clean that resources from the memory.
So in case of string anytime when we manipulate the string over and over again we have some many objects Created ans stay there at in the memory.
So this is the story of string Variable.
Now Let's look at toward StringBuilder Object. For Example:
using System;
using System.Text;
namespace StringVsStrigBuilder
{
class Program
{
static void Main(string[] args)
{
// StringBuilder Example
StringBuilder name = new StringBuilder();
name.Append("Rehan");
name.Append("Shah");
name.Append("RS");
name.Append("---");
name.Append("I love to write programs.");
// Now when I run this program this output will be look like this.
// output : "Rehan Shah Rs --- I love to write programs."
}
}
}
So in this case we are going to changing same object 5-times.
So the Obvious question is that ! What is actually happen under the hood, when we change the same StringBuilder 5-times.
This is What Happen when we change the same StringBuilder 5-times.
let look at the figure.
Explaination: In case of StringBuilder object. you wouldn't get the new object. The same object will be change in memory so even if you change the object et say 10,000 times we will still have only one stringBuilder object.
You don't have alot of garbage objects or non_referenced stringBuilder objects because why it can be change. It is mutable meaning it change over a time?
Differences:
- String is present in System namespace where as Stringbuilder present in System.Text namespace.
- string is immutable where as StringBuilder is mutabe.
In .NET, StringBuilder is still faster than appending strings. I'm pretty sure that in Java, they just create a StringBuffer under the hood when you append strings, so there's isn't really a difference. I'm not sure why they haven't done this in .NET yet.
StringBuilder is significantly more efficient but you will not see that performance unless you are doing a large amount of string modification.
Below is a quick chunk of code to give an example of the performance. As you can see you really only start to see a major performance increase when you get into large iterations.
As you can see the 200,000 iterations took 22 seconds while the 1 million iterations using the StringBuilder was almost instant.
string s = string.Empty;
StringBuilder sb = new StringBuilder();
Console.WriteLine("Beginning String + at " + DateTime.Now.ToString());
for (int i = 0; i <= 50000; i++)
{
s = s + 'A';
}
Console.WriteLine("Finished String + at " + DateTime.Now.ToString());
Console.WriteLine();
Console.WriteLine("Beginning String + at " + DateTime.Now.ToString());
for (int i = 0; i <= 200000; i++)
{
s = s + 'A';
}
Console.WriteLine("Finished String + at " + DateTime.Now.ToString());
Console.WriteLine();
Console.WriteLine("Beginning Sb append at " + DateTime.Now.ToString());
for (int i = 0; i <= 1000000; i++)
{
sb.Append("A");
}
Console.WriteLine("Finished Sb append at " + DateTime.Now.ToString());
Console.ReadLine();
Result of the above code:
Beginning String + at 28/01/2013 16:55:40.
Finished String + at 28/01/2013 16:55:40.
Beginning String + at 28/01/2013 16:55:40.
Finished String + at 28/01/2013 16:56:02.
Beginning Sb append at 28/01/2013 16:56:02.
Finished Sb append at 28/01/2013 16:56:02.
As a general rule of thumb, if I have to set the value of the string more than once, or if there are any appends to the string, then it needs to be a string builder. I have seen applications that I have written in the past before learning about string builders that have had a huge memory foot print that just seems to keep growing and growing. Changing these programs to use the string builder cut down the memory usage significantly. Now I swear by the string builder.
I believe StringBuilder is faster if you have more than 4 strings you need to append together. Plus it can do some cool things like AppendLine.
StringBuilder is preferable IF you are doing multiple loops, or forks in your code pass... however, for PURE performance, if you can get away with a SINGLE string declaration, then that is much more performant.
For example:
string myString = "Some stuff" + var1 + " more stuff"
+ var2 + " other stuff" .... etc... etc...;
is more performant than
StringBuilder sb = new StringBuilder();
sb.Append("Some Stuff");
sb.Append(var1);
sb.Append(" more stuff");
sb.Append(var2);
sb.Append("other stuff");
// etc.. etc.. etc..
In this case, StringBuild could be considered more maintainable, but is not more performant than the single string declaration.
9 times out of 10 though... use the string builder.
On a side note: string + var is also more performant that the string.Format approach (generally) that uses a StringBuilder internally (when in doubt... check reflector!)
Consider 'The Sad Tragedy of Micro-Optimization Theater'.
String and StringBuilder are actually both immutable, the StringBuilder has built in buffers which allow its size to be managed more efficiently. When the StringBuilder needs to resize is when it is re-allocated on the heap. By default it is sized to 16 characters, you can set this in the constructor.
eg.
StringBuilder sb = new StringBuilder(50);
StringBuilder is preferable IF you are doing multiple loops, or forks in your code pass... however, for PURE performance, if you can get away with a SINGLE string declaration, then that is much more performant.
For example:
string myString = "Some stuff" + var1 + " more stuff"
+ var2 + " other stuff" .... etc... etc...;
is more performant than
StringBuilder sb = new StringBuilder();
sb.Append("Some Stuff");
sb.Append(var1);
sb.Append(" more stuff");
sb.Append(var2);
sb.Append("other stuff");
// etc.. etc.. etc..
In this case, StringBuild could be considered more maintainable, but is not more performant than the single string declaration.
9 times out of 10 though... use the string builder.
On a side note: string + var is also more performant that the string.Format approach (generally) that uses a StringBuilder internally (when in doubt... check reflector!)
Using strings for concatenation can lead to a runtime complexity on the order of O(n^2).
If you use a StringBuilder, there is a lot less copying of memory that has to be done. With the StringBuilder(int capacity) you can increase performance if you can estimate how large the final String is going to be. Even if you're not precise, you'll probably only have to grow the capacity of StringBuilder a couple of times which can help performance also.
I believe StringBuilder is faster if you have more than 4 strings you need to append together. Plus it can do some cool things like AppendLine.
This benchmark shows that regular concatenation is faster when combining 3 or fewer strings.
http://www.chinhdo.com/20070224/stringbuilder-is-not-always-faster/
StringBuilder can make a very significant improvement in memory usage, especially in your case of adding 500 strings together.
Consider the following example:
string buffer = "The numbers are: ";
for( int i = 0; i < 5; i++)
{
buffer += i.ToString();
}
return buffer;
What happens in memory? The following strings are created:
1 - "The numbers are: "
2 - "0"
3 - "The numbers are: 0"
4 - "1"
5 - "The numbers are: 01"
6 - "2"
7 - "The numbers are: 012"
8 - "3"
9 - "The numbers are: 0123"
10 - "4"
11 - "The numbers are: 01234"
12 - "5"
13 - "The numbers are: 012345"
By adding those five numbers to the end of the string we created 13 string objects! And 12 of them were useless! Wow!
StringBuilder fixes this problem. It is not a "mutable string" as we often hear (all strings in .NET are immutable). It works by keeping an internal buffer, an array of char. Calling Append() or AppendLine() adds the string to the empty space at the end of the char array; if the array is too small, it creates a new, larger array, and copies the buffer there. So in the example above, StringBuilder might only need a single array to contain all 5 additions to the string-- depending on the size of its buffer. You can tell StringBuilder how big its buffer should be in the constructor.
String concatenation will cost you more. In Java, You can use either StringBuffer or StringBuilder based on your need. If you want a synchronized, and thread safe implementation, go for StringBuffer. This will be faster than the String concatenation.
If you do not need synchronized or Thread safe implementation, go for StringBuilder. This will be faster than String concatenation and also faster than StringBuffer as their is no synchorization overhead.
I have seen significant performance gains from using the EnsureCapacity(int capacity) method call on an instance of StringBuilder before using it for any string storage. I usually call that on the line of code after instantiation. It has the same effect as if you instantiate the StringBuilder like this:
var sb = new StringBuilder(int capacity);
This call allocates needed memory ahead of time, which causes fewer memory allocations during multiple Append() operations. You have to make an educated guess on how much memory you will need, but for most applications this should not be too difficult. I usually err on the side of a little too much memory (we are talking 1k or so).
As a general rule of thumb, if I have to set the value of the string more than once, or if there are any appends to the string, then it needs to be a string builder. I have seen applications that I have written in the past before learning about string builders that have had a huge memory foot print that just seems to keep growing and growing. Changing these programs to use the string builder cut down the memory usage significantly. Now I swear by the string builder.
I have seen significant performance gains from using the EnsureCapacity(int capacity) method call on an instance of StringBuilder before using it for any string storage. I usually call that on the line of code after instantiation. It has the same effect as if you instantiate the StringBuilder like this:
var sb = new StringBuilder(int capacity);
This call allocates needed memory ahead of time, which causes fewer memory allocations during multiple Append() operations. You have to make an educated guess on how much memory you will need, but for most applications this should not be too difficult. I usually err on the side of a little too much memory (we are talking 1k or so).
I believe StringBuilder is faster if you have more than 4 strings you need to append together. Plus it can do some cool things like AppendLine.
My approach has always been to use StringBuilder when concatenating 4 or more strings OR When I don't know how may concatenations are to take place.
Using strings for concatenation can lead to a runtime complexity on the order of O(n^2).
If you use a StringBuilder, there is a lot less copying of memory that has to be done. With the StringBuilder(int capacity) you can increase performance if you can estimate how large the final String is going to be. Even if you're not precise, you'll probably only have to grow the capacity of StringBuilder a couple of times which can help performance also.
StringBuilder is better for building up a string from many non-constant values.
If you're building up a string from a lot of constant values, such as multiple lines of values in an HTML or XML document or other chunks of text, you can get away with just appending to the same string, because almost all compilers do "constant folding", a process of reducing the parse tree when you have a bunch of constant manipulation (it's also used when you write something like int minutesPerYear = 24 * 365 * 60). And for simple cases with non-constant values appended to each other, the .NET compiler will reduce your code to something similar to what StringBuilder does.
But when your append can't be reduced to something simpler by the compiler, you'll want a StringBuilder. As fizch points out, that's more likely to happen inside of a loop.
StringBuilder is probably preferable. The reason is that it allocates more space than currently needed (you set the number of characters) to leave room for future appends. Then those future appends that fit in the current buffer don't require any memory allocation or garbage collection, which can be expensive. In general, I use StringBuilder for complex string concatentation or multiple formatting, then convert to a normal String when the data is complete, and I want an immutable object again.
String concatenation will cost you more. In Java, You can use either StringBuffer or StringBuilder based on your need. If you want a synchronized, and thread safe implementation, go for StringBuffer. This will be faster than the String concatenation.
If you do not need synchronized or Thread safe implementation, go for StringBuilder. This will be faster than String concatenation and also faster than StringBuffer as their is no synchorization overhead.
StringBuilder reduces the number of allocations and assignments, at a cost of extra memory used. Used properly, it can completely remove the need for the compiler to allocate larger and larger strings over and over until the result is found.
string result = "";
for(int i = 0; i != N; ++i)
{
result = result + i.ToString(); // allocates a new string, then assigns it to result, which gets repeated N times
}
vs.
String result;
StringBuilder sb = new StringBuilder(10000); // create a buffer of 10k
for(int i = 0; i != N; ++i)
{
sb.Append(i.ToString()); // fill the buffer, resizing if it overflows the buffer
}
result = sb.ToString(); // assigns once
Using strings for concatenation can lead to a runtime complexity on the order of O(n^2).
If you use a StringBuilder, there is a lot less copying of memory that has to be done. With the StringBuilder(int capacity) you can increase performance if you can estimate how large the final String is going to be. Even if you're not precise, you'll probably only have to grow the capacity of StringBuilder a couple of times which can help performance also.
To clarify what Gillian said about 4 string, if you have something like this:
string a,b,c,d;
a = b + c + d;
then it would be faster using strings and the plus operator. This is because (like Java, as Eric points out), it internally uses StringBuilder automatically (Actually, it uses a primitive that StringBuilder also uses)
However, if what you are doing is closer to:
string a,b,c,d;
a = a + b;
a = a + c;
a = a + d;
Then you need to explicitly use a StringBuilder. .Net doesn't automatically create a StringBuilder here, because it would be pointless. At the end of each line, "a" has to be an (immutable) string, so it would have to create and dispose a StringBuilder on each line. For speed, you'd need to use the same StringBuilder until you're done building:
string a,b,c,d;
StringBuilder e = new StringBuilder();
e.Append(b);
e.Append(c);
e.Append(d);
a = e.ToString();
String and StringBuilder are actually both immutable, the StringBuilder has built in buffers which allow its size to be managed more efficiently. When the StringBuilder needs to resize is when it is re-allocated on the heap. By default it is sized to 16 characters, you can set this in the constructor.
eg.
StringBuilder sb = new StringBuilder(50);
Further to the previous answers, the first thing I always do when thinking of issues like this is to create a small test application. Inside this app, perform some timing test for both scenarios and see for yourself which is quicker.
IMHO, appending 500+ string entries should definitely use StringBuilder.
I have seen significant performance gains from using the EnsureCapacity(int capacity) method call on an instance of StringBuilder before using it for any string storage. I usually call that on the line of code after instantiation. It has the same effect as if you instantiate the StringBuilder like this:
var sb = new StringBuilder(int capacity);
This call allocates needed memory ahead of time, which causes fewer memory allocations during multiple Append() operations. You have to make an educated guess on how much memory you will need, but for most applications this should not be too difficult. I usually err on the side of a little too much memory (we are talking 1k or so).
In .NET, StringBuilder is still faster than appending strings. I'm pretty sure that in Java, they just create a StringBuffer under the hood when you append strings, so there's isn't really a difference. I'm not sure why they haven't done this in .NET yet.
Further to the previous answers, the first thing I always do when thinking of issues like this is to create a small test application. Inside this app, perform some timing test for both scenarios and see for yourself which is quicker.
IMHO, appending 500+ string entries should definitely use StringBuilder.
String and StringBuilder are actually both immutable, the StringBuilder has built in buffers which allow its size to be managed more efficiently. When the StringBuilder needs to resize is when it is re-allocated on the heap. By default it is sized to 16 characters, you can set this in the constructor.
eg.
StringBuilder sb = new StringBuilder(50);
My approach has always been to use StringBuilder when concatenating 4 or more strings OR When I don't know how may concatenations are to take place.
StringBuilder is better for building up a string from many non-constant values.
If you're building up a string from a lot of constant values, such as multiple lines of values in an HTML or XML document or other chunks of text, you can get away with just appending to the same string, because almost all compilers do "constant folding", a process of reducing the parse tree when you have a bunch of constant manipulation (it's also used when you write something like int minutesPerYear = 24 * 365 * 60). And for simple cases with non-constant values appended to each other, the .NET compiler will reduce your code to something similar to what StringBuilder does.
But when your append can't be reduced to something simpler by the compiler, you'll want a StringBuilder. As fizch points out, that's more likely to happen inside of a loop.
Yes, StringBuilder gives better performance while performing repeated operation over a string. It is because all the changes are made to a single instance so it can save a lot of time instead of creating a new instance like String.
String Vs Stringbuilder
String- under
Systemnamespace - immutable (read-only) instance
- performance degrades when continuous change of value occures
- thread safe
- under
StringBuilder(mutable string)- under
System.Textnamespace - mutable instance
- shows better performance since new changes are made to existing instance
- under
Strongly recommend dotnet mob article : String Vs StringBuilder in C#.
Related Stack Overflow question: Mutability of string when string doesn't change in C#?.
Further to the previous answers, the first thing I always do when thinking of issues like this is to create a small test application. Inside this app, perform some timing test for both scenarios and see for yourself which is quicker.
IMHO, appending 500+ string entries should definitely use StringBuilder.
StringBuilder is better for building up a string from many non-constant values.
If you're building up a string from a lot of constant values, such as multiple lines of values in an HTML or XML document or other chunks of text, you can get away with just appending to the same string, because almost all compilers do "constant folding", a process of reducing the parse tree when you have a bunch of constant manipulation (it's also used when you write something like int minutesPerYear = 24 * 365 * 60). And for simple cases with non-constant values appended to each other, the .NET compiler will reduce your code to something similar to what StringBuilder does.
But when your append can't be reduced to something simpler by the compiler, you'll want a StringBuilder. As fizch points out, that's more likely to happen inside of a loop.
This benchmark shows that regular concatenation is faster when combining 3 or fewer strings.
http://www.chinhdo.com/20070224/stringbuilder-is-not-always-faster/
StringBuilder can make a very significant improvement in memory usage, especially in your case of adding 500 strings together.
Consider the following example:
string buffer = "The numbers are: ";
for( int i = 0; i < 5; i++)
{
buffer += i.ToString();
}
return buffer;
What happens in memory? The following strings are created:
1 - "The numbers are: "
2 - "0"
3 - "The numbers are: 0"
4 - "1"
5 - "The numbers are: 01"
6 - "2"
7 - "The numbers are: 012"
8 - "3"
9 - "The numbers are: 0123"
10 - "4"
11 - "The numbers are: 01234"
12 - "5"
13 - "The numbers are: 012345"
By adding those five numbers to the end of the string we created 13 string objects! And 12 of them were useless! Wow!
StringBuilder fixes this problem. It is not a "mutable string" as we often hear (all strings in .NET are immutable). It works by keeping an internal buffer, an array of char. Calling Append() or AppendLine() adds the string to the empty space at the end of the char array; if the array is too small, it creates a new, larger array, and copies the buffer there. So in the example above, StringBuilder might only need a single array to contain all 5 additions to the string-- depending on the size of its buffer. You can tell StringBuilder how big its buffer should be in the constructor.
My approach has always been to use StringBuilder when concatenating 4 or more strings OR When I don't know how may concatenations are to take place.
StringBuilder is probably preferable. The reason is that it allocates more space than currently needed (you set the number of characters) to leave room for future appends. Then those future appends that fit in the current buffer don't require any memory allocation or garbage collection, which can be expensive. In general, I use StringBuilder for complex string concatentation or multiple formatting, then convert to a normal String when the data is complete, and I want an immutable object again.
StringBuilder will perform better, from a memory stand point. As for processing, the difference in time of execution may be negligible.
Source: Stackoverflow.com