Comment Feed for C# string vs. StringBuilder (TechOff on Channel 9)

Re: Re: C# string vs. StringBuilder

BitFlipper — Sun, 22 Nov 2009 20:33:56 GMT

You should use Stopwatch to measure small time increments. It has a very high resolution and low overhead.

Re: Re: Re: Re: Re: Re: Re: C# string vs. StringBuilder

stevo_ — Fri, 16 Jan 2009 18:28:19 GMT

Fella, you quoted me.. my initial response, and counter clarification response (due to you responding TO me) was aimed at the poster I originally quoted.

Boom, your high horse just got executed.

Re: Re: Re: Re: Re: Re: C# string vs. StringBuilder

JR Thomas — Fri, 16 Jan 2009 18:10:32 GMT

Not sure what your talking about. None of my replys include a link to any of my blog posts.

Yes my blog is connected to my Channel 9 profile. But anyone who takes half a second to do this also has the option.

I make no money off my blog. Its on a public service.

I am not sure if you get some form of theraputic benifit on being a tool but really your flaming has no basis. If it made you feel less depressed don't let me get in the way of whatever therapy you and your shrink have worked out.

Re: Re: Re: Re: Re: C# string vs. StringBuilder

evildictaitor — Fri, 16 Jan 2009 10:14:01 GMT

You remember reading wrong - stringbuilders have no idea how big they'll need to be by the end, and so they have to occassionally expand themselves (an expensive operation) when they find out they have run out of space. String.Concat() on the other hand can work out exactly how long the result will be (it's the sum of all of the individual strings' lengths) and so String.Concat() is faster.

For large strings or large numbers of concats, String.Concat becomes even more efficient.

As a rule of thumb - for concatenating strings, use String.Concat. For building strings, use a StringBuilder.

Re: Re: Re: Re: Re: C# string vs. StringBuilder

stevo_ — Thu, 15 Jan 2009 18:29:02 GMT

I mean't, don't post uninspired boring links to your own blog posts, especially when the post isn't very good.. clearly the massive views of this thread (for obvious reasons) are attractive.. hmmmm views == readers of my blog.. ka ching! $$$

Re: Re: Re: Re: C# string vs. StringBuilder

JR Thomas — Thu, 15 Jan 2009 18:09:43 GMT

My general rule of thumb is to use string concatenation or string.Format up to 3 concats. Afterwhich I will go to the trouble of using a string builder or some kind of stream writer. I remember reading that string concats are more performat up to 3 concats then it goes south from there.

Probably unless your doing fairly intensive concating it won't be that big of deal. Most devs I work with brush it off.

Re: Re: Re: C# string vs. StringBuilder

stevo_ — Thu, 15 Jan 2009 15:30:20 GMT

Please don't do that.

Re: Re: C# string vs. StringBuilder

Robin Thomas — Thu, 15 Jan 2009 15:17:30 GMT

A performance comparison of StringBuilder and String can be found in the following post

http://rttechno.blogspot.com/2009/01/stringbuilder-vs-string-concatenations.html

Re: C# string vs. StringBuilder

figuerres — Thu, 18 Oct 2007 16:34:28 GMT

tim2s wrote:
dbCommand Cmd = new dbCommand( "Insert (x,y,z) values(@Name,@name2..." );
Parameter P1 = new Parameter( "@Name", dbtype);

Cmd.Parameters.Add(P1);

and so on then .. in the loop:

for()
{
P1 = value;
P2 = other;
P3 = "what";
Cmd.ExecuteNonQuery();
}

no making strings in the loop, and no creating cmd's in a loop.
this makes for nice clean code that runs fast.

Thank you,

but i write into an *.mpl, which can not be used with the incredible SqlConnction. I have to fight with strings into an OleDb.

But maybe i can convince them to use an Sql Express Db

well i would go for sql express for many reasons but...

System.Data.OleDb.OleDbCommand odb = new System.Data.OleDb.OleDbCommand("");
odb.Parameters.Add();

I think the ole db parpameter makers are '?' in place of '@name'
but the rest should I think work with oledb as well as sql, and I think odbc supports parameters also.

Re: C# string vs. StringBuilder

tim2s — Thu, 18 Oct 2007 15:51:57 GMT

dbCommand Cmd = new dbCommand( "Insert (x,y,z) values(@Name,@name2..." );
Parameter P1 = new Parameter( "@Name", dbtype);

Cmd.Parameters.Add(P1);

and so on then .. in the loop:

for()
{
P1 = value;
P2 = other;
P3 = "what";
Cmd.ExecuteNonQuery();
}

no making strings in the loop, and no creating cmd's in a loop.
this makes for nice clean code that runs fast.

Thank you,

but i write into an *.mpl, which can not be used with the incredible SqlConnction. I have to fight with strings into an OleDb.

But maybe i can convince them to use an Sql Express Db ;)

Re: C# string vs. StringBuilder

evildictaitor — Mon, 15 Oct 2007 17:15:53 GMT

For a stringbuilder, a constant "cost" of expanding the capacity is linear w.r.t the previous capacity.

If you choose your initial value for the StringBuilder capacity carefully, it is nearly always the most efficient solution.

So.

For small or strictly constant strings, System.String is valid. For large strings, construction of strings other than with String.Format() or for strings which need to change quickly and can be large (e.g. the Value field in a text-editor or syntax editor), use a System.StringBuilder.

In the event that you want to be able to change text even faster (or holding really big values), then you'll start needing to construct your own data types over this (e.g. a linked-list of stringbuilders is more efficient for insertion than a mege-stringbuilder, both of which are vastly better than a System.String).

Re: C# string vs. StringBuilder

odujosh — Mon, 15 Oct 2007 16:50:41 GMT

travis wrote:

Well, maybe I'll just post my code. I'm wondering if I should guess the approximate length of a stringbuilder when I create it, or just let it grow dynamically:

System.Text.StringBuilder letterNavText = new System.Text.StringBuilder(1106);
letterNavText.Append("");
for (int i = (int)'A'; i <= (int)'Z'; i++)
{
string letter = ((char)i).ToString();
if (letter == SelectedLetter)
{
 letterNavText.Append("");
 letterNavText.Append(letter);
 letterNavText.Append("");
}
else
{
 letterNavText.Append("<a href=\"");
 letterNavText.Append(letter);
 letterNavText.Append(".htm\" title=\"");
 letterNavText.Append(letter);
 letterNavText.Append("\">");
 letterNavText.Append(letter);
 letterNavText.Append("</a>");
}
letterNavText.Append("  ");
}
letterNavText.Append("");
LetterNav.InnerHtml = letterNavText.ToString();

Previous post referred to this little nugget. Sorry one of my pet peeves. If you want it I can post a sample that does just this using a repeater.

Re: C# string vs. StringBuilder

odujosh — Mon, 15 Oct 2007 14:19:14 GMT

Use a repeater control. Why are using making your own? :)

Re: C# string vs. StringBuilder

Sven Groot — Mon, 15 Oct 2007 01:54:05 GMT

If the thread is that old and your topic is only marginally related, start a new thread.

Anyway, in your case I'd recommend using parameterized queries rather than doing string concatenation at all.

Example:

using( OleDbCommand cmd = connection.CreateCommand() )
{
   cmd.CommandText = "INSERT INTO TBLNAME (x, y, z) VALUES (?, ?, ?)";
   cmd.Parameters.AddWithValue("x", xValue);
   cmd.Parameters.AddWithValue("y", yValue);
   cmd.Parameters.AddWithValue("z", zValue);
   cmd.ExecuteNonQuery();
}

Not only does it remove the need for string concatenation, it eliminates the risk of SQL injection as well.

Re: C# string vs. StringBuilder

figuerres — Mon, 15 Oct 2007 01:53:59 GMT

tim2s wrote:
Hello !

I have got a Problem that is related to this topic.
I have to copy Data from one Database to an Access db and make
some computing during this transfer.

There are quite a lot of records, estimated 40K per table with several tables.

Until now i'm doing the following thing for the inser Operation:

for(int i = 0; i < myDataList.Count; i++) {

cmdText = "INSERT INTO TBLNAME (x,y,z) VALUES "( ";
cmdText += xValue + ", " + yValue + ", " + zValue + " )";

DbWriter.ExecuteNonReader(cmdText);

}

Where DbWriter is a class with static Functions for Capsulating the database connection.

Do you think it would be more useful to use a StringBuilder in this case? I mean the text has to be resetted for every item in the List, so there will be a new StringBuilder Object for every row. Is this still faster?

Best Regards,
Tim

before the loop create a dbCommand and add a collection of Parameters. then set the parameter values and call execute.
you will remove a whole bunch of strings ....

dbCommand Cmd = new dbCommand( "Insert (x,y,z) values(@Name,@name2..." );
Parameter P1 = new Parameter( "@Name", dbtype);

Cmd.Parameters.Add(P1);

and so on then .. in the loop:

for()
{
P1 = value;
P2 = other;
P3 = "what";
Cmd.ExecuteNonQuery();
}

no making strings in the loop, and no creating cmd's in a loop.
this makes for nice clean code that runs fast.

Re: C# string vs. StringBuilder

tim2s — Sun, 14 Oct 2007 21:55:23 GMT

Hello !

I have got a Problem that is related to this topic.
I have to copy Data from one Database to an Access db and make
some computing during this transfer.

There are quite a lot of records, estimated 40K per table with several tables.

Until now i'm doing the following thing for the inser Operation:

for(int i = 0; i < myDataList.Count; i++) {

cmdText = "INSERT INTO TBLNAME (x,y,z) VALUES "( ";
cmdText += xValue + ", " + yValue + ", " + zValue + " )";

DbWriter.ExecuteNonReader(cmdText);

}

Where DbWriter is a class with static Functions for Capsulating the database connection.

Do you think it would be more useful to use a StringBuilder in this case? I mean the text has to be resetted for every item in the List, so there will be a new StringBuilder Object for every row. Is this still faster?

Best Regards,
Tim

Re: C# string vs. StringBuilder

Maurits — Fri, 14 Oct 2005 16:07:36 GMT

travis wrote:

{
 letterNavText.Append("<a href=\"");
 letterNavText.Append(letter);
 letterNavText.Append(".htm\" title=\"");
 letterNavText.Append(letter);
 letterNavText.Append("\">");
 letterNavText.Append(letter);
 letterNavText.Append("</a>");
}

I think you can get away with
letterNavText.Append(
"<a href=\"" + letter + ".htm\" title=\"" + letter + "\">" + letter + "</a>"
);

because multiple string concatenations in a single statement are auto-optimized with an inline StringBuilder replacement.

Re: C# string vs. StringBuilder

kriskdf — Fri, 14 Oct 2005 15:57:47 GMT

MisterDonut wrote:
String.Format("{0}{1}{2}{3}", string1, string2, string3);

For perf reasons, you should consider String.Concat(string1, string2, string3) instead of the formating. If it is only called once in your program, it probably doesn't matter, but if you are doing something over and over again, it might be worth looking into the change.

String.Concat (if I remember correctly) sums up the lengths of all the strings, build a buffer, then places the contents into that buffer. It only allocates what it needs (different than stringbuilder).

If you are using string builder and you know how about how much space you will need, definitly instantiate it with a default capacity.

I also encourage everyone to look at the Rotor source code to figure out how these things work. It will help you make informed decisions. But keep in mind that the Rotor source may be different than the actual MS implementation and the MS implementation could change at any time.

Also, measure perf to make good decisions.

Re: C# string vs. StringBuilder

Tom Servo — Fri, 14 Oct 2005 15:37:12 GMT

A StringBuilder does all its operations in a given block of allocated memory. E.g. if you add something to a string, it appends it at the marked end of string, in the same memory block. A regular string operation would allocate a new chunk and copy both strings into the new chunk. It's more work.

However since the StringBuilder needs to be instanced and all that stuff, it's not efficient enough if you're always just quickly adding two strings together, as opposed to for example composing a whole HTML page.

Re: C# string vs. StringBuilder

bushidocoder — Fri, 14 Oct 2005 15:20:12 GMT

MisterDonut wrote:
One thing I do to create strings, for smaller ones, but still don't want to concatenate is this:

String.Format("{0}{1}{2}{3}", string1, string2, string3);

Substuting string1-3 with the characters of your choice.

Seems to work pretty well.

If you crack open String.Format, it creates a StringBuilder internally and uses StringBuilder.AppendFormat to accomplish its goal.

Each call to String.Format results in the the allocation of an instance of StringBuilder - I've only looked at it for two minutes or so, but it appears that StringBuilder.AppendFormat doesn't attempt to estimate the size of the eventual output, so if you're just using it to append strings together, you could find out how large the output is supposed to be and use a StringBuffer with a predetermined capacity to do the appending.

That said, in my own code, I just append the things together for code cleanliness and if that ever shows up in our profiling roadmaps, I'll come back and clean it up. To date, for at least the work I do, inefficient string appending has been a nonfactor.

Re: C# string vs. StringBuilder

MisterDonut — Fri, 14 Oct 2005 15:05:07 GMT

One thing I do to create strings, for smaller ones, but still don't want to concatenate is this:

String.Format("{0}{1}{2}{3}", string1, string2, string3);

Substuting string1-3 with the characters of your choice.

Seems to work pretty well.

Re: C# string vs. StringBuilder

Skibum — Wed, 28 Jul 2004 16:02:01 GMT

For reference...

The StringBuilder's initial capacity is set to 16 by default. The capacity then increases by an order of 2 whenever the current capacity is passed. Therefore, if the String you append to the StringBuilder causes the capacity to expand, it will increase as seen below:

 StringBuilder sb =
 new System.Text.StringBuilder();
 int capacity = sb.Capacity;

 for (int i=0; i<5000; i++)
 {
 sb.Append("a");
 if (capacity != sb.Capacity)
 {
 PrintLine("Capacity: " + sb.Capacity);
 }
 capacity = sb.Capacity;
 }

results in the following capacity adjustments:
Capacity: 16
Capacity: 32
Capacity: 64
Capacity: 128
Capacity: 256
Capacity: 512
Capacity: 1024
Capacity: 2048
Capacity: 4096
Capacity: 8192

Re: C# string vs. StringBuilder

travis — Wed, 28 Jul 2004 14:57:21 GMT

Well, maybe I'll just post my code. I'm wondering if I should guess the approximate length of a stringbuilder when I create it, or just let it grow dynamically:

System.Text.StringBuilder letterNavText = new System.Text.StringBuilder(1106);
letterNavText.Append("");
for (int i = (int)'A'; i <= (int)'Z'; i++)
{
string letter = ((char)i).ToString();
if (letter == SelectedLetter)
{
 letterNavText.Append("");
 letterNavText.Append(letter);
 letterNavText.Append("");
}
else
{
 letterNavText.Append("<a href=\"");
 letterNavText.Append(letter);
 letterNavText.Append(".htm\" title=\"");
 letterNavText.Append(letter);
 letterNavText.Append("\">");
 letterNavText.Append(letter);
 letterNavText.Append("</a>");
}
letterNavText.Append("  ");
}
letterNavText.Append("");
LetterNav.InnerHtml = letterNavText.ToString();

Re: C# string vs. StringBuilder

travis — Wed, 28 Jul 2004 14:11:17 GMT

jonathanh wrote:
There was a semi-spirited discussion of this very topic on some Microsoft blogs a while back :-)

I found the blog posts again using "site:blogs.msdn.com string stringbuilder" as a Google query.

Whoa, 83 results! I'll start skimming and come back here if I'm still confused. Thanks!

Re: C# string vs. StringBuilder

jonathanh — Wed, 28 Jul 2004 06:13:57 GMT

There was a semi-spirited discussion of this very topic on some Microsoft blogs a while back :-)

I found the blog posts again using "site:blogs.msdn.com string stringbuilder" as a Google query.