String Builder efficiency

[Chris Dunaway]

I am using a StringBuilder like this:

Dim sb As New StringBuilder

sb.Append("Text field 1: {TXT1}" & VbCrLf)
sb.Append("Text field 2: {TXT2}" & VbCrLf)
sb.Append("Text field 3: {TXT3}" & VbCrLf)

And then later in the code I use this:

Dim sText1Value As String
Dim sText2Value As String
Dim sText3Value As String

sb.Replace("{TXT1}", sText1Value)
sb.Replace("{TXT2}", sText2Value)
sb.Replace("{TXT3}", sText3Value)

My question concerns the length of the string values in the sText1Value
variables. What if their lengths are greater than the tokens ({TXT1},
{TXT2}) that I inserted into the StringBuilder at the beginning?

Will that cause an unnecessary string allocation? Should I make the
tokens as long as the maximum string length that I think will be
replaced? e. g. :

sb.Append("Text field 1: {TXT1LONGTOKENLENGTH}" & VbCrLf)

Would the StringBuilder still have to make an extra string allocation
in this case or would it just be able to replace the characters in
place? Should I even be concerned about it?

I could not examine the Replace function with ILDASM or Reflector to
see exactly what it did.

Thanks

 

[AlexS]

Chris,

you can easily try this code and see the results.
I am not sure what is your concern. Do you have any problems with
sb.Replace?
What do you expect to be maximum length in method call?

As about "average joe" situation, replace 1 character with string of 20
works.

Allocations you can check with any good enough profiler.

HTH
Alex

 

[Armin Zingler]

I am using a StringBuilder like this:

Dim sb As New StringBuilder

sb.Append("Text field 1: {TXT1}" & VbCrLf)
sb.Append("Text field 2: {TXT2}" & VbCrLf)
sb.Append("Text field 3: {TXT3}" & VbCrLf)

And then later in the code I use this:

Dim sText1Value As String
Dim sText2Value As String
Dim sText3Value As String

sb.Replace("{TXT1}", sText1Value)
sb.Replace("{TXT2}", sText2Value)
sb.Replace("{TXT3}", sText3Value)

My question concerns the length of the string values in the
sText1Value variables. What if their lengths are greater than the
tokens ({TXT1}, {TXT2}) that I inserted into the StringBuilder at the
beginning?

Will that cause an unnecessary string allocation? Should I make
the tokens as long as the maximum string length that I think will
be replaced? e. g. :

sb.Append("Text field 1: {TXT1LONGTOKENLENGTH}" & VbCrLf)

Would the StringBuilder still have to make an extra string
allocation in this case or would it just be able to replace the
characters in place? Should I even be concerned about it?

I could not examine the Replace function with ILDASM or Reflector
to see exactly what it did.

Thanks

I think there is no big difference between adding new chars/strings to the
stringbuilder and replacing parts by longer strings. In both cases it is
possible that the current capacity is exceeded. In general, the initial
capcity I choose for the stringbuilder is about the size I expect the length
will be - unless I have no clue about the size, but this depends on the
case.

BTW, you should use

sb.Append("Text field 1: {TXT1}")
sb.Append(vbCrLf)

instead to avoid unncessary string concatenations.


Armin

 

[Oenone]

BTW, you should use

sb.Append("Text field 1: {TXT1}")
sb.Append(vbCrLf)

instead to avoid unncessary string concatenations.

Surely the compiler would take care of that particular concatenation at
compile time and reduce it to a single string? If there were variables
involved then sure, that would be more efficient as multiple .Append calls.
But when concatenating multiple string literals, I'm sure the compiler
should put these together as a single string in the output code..?

 

[Armin Zingler]

Surely the compiler would take care of that particular concatenation
at compile time and reduce it to a single string? If there were
variables involved then sure, that would be more efficient as
multiple .Append calls. But when concatenating multiple string
literals, I'm sure the compiler should put these together as a
single string in the output code..?

You're right, the compiler recognizes this. I didn't rely on it. ;-)

Armin

 

[Cor Ligthert]

Armin,

You're right, the compiler recognizes this. I didn't rely on it. ;-)

Because you was a while not active in this newsgroup. Has been a long and
deep discussed subject.

)

Cor

 

[Armin Zingler]

Armin,


Because you was a while not active in this newsgroup. Has been a long
and deep discussed subject.

)

Cor

Ah, ok, I didn't know this.

Armin