By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,641 Members | 1,446 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,641 IT Pros & Developers. It's quick & easy.

String Builder efficiency

P: n/a
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

Nov 21 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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

"Chris Dunaway" <du******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
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

Nov 21 '05 #2

P: n/a
"Chris Dunaway" <du******@gmail.com> schrieb
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

Nov 21 '05 #3

P: n/a
Armin Zingler wrote:
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..?

--

(O)enone
Nov 21 '05 #4

P: n/a
"Oenone" <oe****@nowhere.com> schrieb
Armin Zingler wrote:
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..?

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

Armin
Nov 21 '05 #5

P: n/a
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
Nov 21 '05 #6

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb
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


Ah, ok, I didn't know this. :-)

Armin
Nov 21 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.