stringBuilder vs string concatenation myth of usage...

[genc ymeri]

However, if you're concatenating a couple of dozen strings inside a

loop that executes an unknown number of times, then Jon's tests apply
and you should use StringBuilder.

Absolutely. I'm not even questioning this.

Thanks

 

[Stephany Young]

Firstly, what is the point of all the white space between the end of the
text for each 'line' and the end of the strings?

Secondly, you are only doing 2 concatenations here. The compiler will
optimize the startic part of the string and treat it as a literal, so that
you effectively end up with (white space excluded):

string sqlGetCabinets = "select
distinct\r\nfc.Filecabinet_ID,\r\nfc.Filecabinet_code,\r\nfc.repository_table,\r\nfc.Filecabinet_desc\r\nfrom\r\nRS_GROUP_ASSIGNMENTS\r\n\r\ninner\r\n
join rr_filecabinets fc on\r\nga.object_id = fc.filecabinet_id\r\ninner join
rs_groups g\r\non\r\ng.group_id = ga.group_id\r\ninner join RS_GROUP_DETAILS
gd on\r\ngd.group_id = g.group_id\r\ninner join rs_users u
on\r\ngd.user_id\r\nu.user_id\r\nwhere\r\nu.user_name='";

sqlGetCabinetsstring += aUsername + "'";

The string operations are as follows:

Intial allocation and initialisation of sqlGetCabinets

Concatenation of sqlGetCabinets and aUsername
(New instance of sqlGetCabinets is created and old instance is dumped)

Concatenation of sqlGetCabinets and '
(New instance of sqlGetCabinets is created and old instance is dumped)

If you choose to make the strings pretty by imbedding formatting elements
then you have to be prepared to pay the price for it in memory usage and
performance hits.

 

[Chris Fulstow]

Nope, but something like this *is* easier to read:

string sql = "";
sql += "SELECT " + columns + " ";
sql += "FROM " + tables + " ";
sql += "WHERE " + col1 + " = " + condition1 + " AND col2 = " +
condition2;
sql += "ORDER BY " + order;

Better still with syntax highlighting.

Chris

 

[Bjorn Abelli]

...

....

Secondly, you are only doing 2 concatenations here. The compiler
will optimize the startic part of the string and treat it as a
literal, so that you effectively end up with (white space excluded):

string sqlGetCabinets = "select
distinct\r\nfc.Filecabinet_ID,\r\nfc.Filecabinet_code,\r\nfc.repository_table,\r\nfc.Filecabinet_desc\r\nfrom\r\nRS_GROUP_ASSIGNMENTS\r\n\r\ninner\r\n
join rr_filecabinets fc on\r\nga.object_id = fc.filecabinet_id\r\ninner
join rs_groups g\r\non\r\ng.group_id = ga.group_id\r\ninner join
RS_GROUP_DETAILS gd on\r\ngd.group_id = g.group_id\r\ninner join rs_users
u on\r\ngd.user_id\r\nu.user_id\r\nwhere\r\nu.user_name='";

sqlGetCabinetsstring += aUsername + "'";

I'm not completely sure that it's a good thing if the NewLine is preinserted
at compilation, as I would expect it to give different values on different
platforms.

Anyway, if that's the case, why not write it something like this?

string sqlGetCabinets =
@"select distinct
fc.Filecabinet_ID,
fc.Filecabinet_code,
fc.repository_table,
fc.Filecabinet_desc
from
RS_GROUP_ASSIGNMENTS ga
inner join rr_filecabinets fc on
ga.object_id = fc.filecabinet_id
inner join rs_groups g on
g.group_id = ga.group_id
inner join RS_GROUP_DETAILS gd on
gd.group_id = g.group_id
inner join rs_users u on
gd.user_id = u.user_id
where
u.user_name = '" + aUsername + "'";

That would render it more readable both in the OP's logfile as well as in
the OP's source code.

....or even with the last line as this:

u.user_name = ? ";

....and using a Parameter for the only parameter in the whole statement.

// Bjorn A

 

[Kevin Spencer]

string sql = "";

sql += "SELECT " + columns + " ";
sql += "FROM " + tables + " ";
sql += "WHERE " + col1 + " = " + condition1 + " AND col2 = " +
condition2;
sql += "ORDER BY " + order;

That's a poor example, as it acutally creates 5 string instances. Try:

sql = "SELECT " + columns +
" FROM " + tables +
" WHERE " + col1 + " = " + condition1 +
" AND col2 = " + condition2 +
" ORDER BY " + order;

This example creates a single string instance, while preserving the
readability you want.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

 

[Chris Fulstow]

Agreed. Kevin's example will be compiled as a single String.Concat(),
which is far more efficient. Furthermore, if you're concatenating
literal strings then the compiler will also optimise:

string test = "a" + "b" + "c" + "d" + "e";
/* compiler will initialise string as: */
string test = "abcde";

Chris

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,
sqlGetCabinetsstring += aUsername + "'";

I'm not completely sure that it's a good thing if the NewLine is
preinserted
at compilation, as I would expect it to give different values on different
platforms.

It will not nl is a variable so that invalidate the possible concatenation
of the string by the compiler.

BTW, it's pretty useless to include it, you dont care about the formatting
when you send the query to the server.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Thank a lot Jon and thank you all of you for your input.

Based on all of my tests (writen by me or others), it shows that:

(1) for concatenating 100 lines or less with a
(2) length of [0- 200] characters

the difference of building the result with (+) operator versus the
stringbuilder one is less than 1 nanosecond ( the smalllest unit the
Timespan can track the time).
Concatenation time (ticks) with (+) operator result =+: 0

Again, can you post the code you are using to test, I find HARD to believe
your results

BTW, in the code you posted before GenerateJavascript() if you write this
using concatenation you will end with two concatenations , no sorry three.
vbCrLf is a constant, so it;s not the same as EnvironMent.NewLine

Post your code and lets analize it together.

 

[Bjorn Abelli]

...

It will not nl is a variable so that invalidate the possible
concatenation of the string by the compiler.

I'm not sure I understand your sentence above.

Other posters in this thread say that the "concatenation" of NewLine *will*
be handled by the compiler, because it's not a variable, but a constant
(which also the documentation says in MSDN).

Do you mean that the OP's use of the intermediate variable 'nl' invalidates
that?

Shouldn't the compiler be able to optimize away that anyway?

BTW, it's pretty useless to include it, you dont care about
the formatting when you send the query to the server.

For the OP, it wasn't useless, as the query itself was logged (with the line
breaks)

// Bjorn A

 

[genc ymeri]

Anyway, if that's the case, why not write it something like this?

That's not the point.......

 

[genc ymeri]

If you choose to make the strings pretty by imbedding formatting elements

then you have to be prepared to pay the price for it in memory usage and
performance hits.

Well, finally we got back to the point which really I'm not sure why is not
the main focus here.....

Tests show that there is no performance hit for at least up to 100
concatenations for any string with a length up to 200. (or the performance
hit is behind the measurements).

All I wanted to discuss was how come some expert developers have as a
criterion to start using it stringbuilder for 3 concatenations and up.....

Whatever though,
Thanks for you input.

 

[genc ymeri]

I fully agree,
thanks a lot.

 

[genc ymeri]

I've heard and abide by the rule: If the number of string
concatenations necessary is unknown (as is in your PS case) always use
StringBuilder, otherwise use discretion on your choice.

yup....it make sense,
thanks a lot.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

...


I'm not sure I understand your sentence above.

Neither I do

I think it was a message I sent by mistake , sorry for the mess, it wa
early in the morning and I had no coffee in my MemoryStream yet

Other posters in this thread say that the "concatenation" of NewLine
*will* be handled by the compiler, because it's not a variable, but a
constant (which also the documentation says in MSDN).

Well what happens then if you are running in an environment where NewLine is
different? , IF it was compiled AND concatenated in the string it will
display it wrongly in the new platform.
I just checked MSDN and it says textually ( A string containing "\r\n". )
Which IMO it's a mistake.

But as I just saw in another post of the OP , he is not using NewLine (which
is the correct way to do it) but vbCrLf which is indeed a constant
equivalent to "\r\n" , no idea why he posted in the C# NG when he was using
VB.net , but the post is relevant anyway.

Do you mean that the OP's use of the intermediate variable 'nl'
invalidates that?

Yes, if you use a variable you lose the posibility of the compiler
converting it to a literal, just think, what happens if the variable is
changed from another thread? The compiler cannot assure this so I bet it
will not create the literal concatenating all the strings, it will instead
create a bunch of literals.

Shouldn't the compiler be able to optimize away that anyway?

No, for the reason I mentioned above, as soon as you include a variable it
cannot optimize it. At least that is what I think, I haven't check it
though.

For the OP, it wasn't useless, as the query itself was logged (with the
line breaks)

You are right, if he logs it it does has a difference, I missed that part.