string concatenation

  • Thread starter Thread starter Dominique Vandensteen
  • Start date Start date
D

Dominique Vandensteen

after the very small & vs string.format discussion I did some speed tests...


loop of 1.000.000 concatenations of 5 public string variables in a class
gave following results:


result = a & b & c & d & e
+/- 420ms

result = a
result &= b
result &= c
result &= d
result &= e
+/- 370ms

dim result as new StringBuilder()
result.Append(a)
result.Append(b)
result.Append(c)
result.Append(d)
result.Append(e)
new StringBuilder in each loop: +/- 730ms
new StringBuilder outside + result.length=0 in each loop: +/- 690ms

result = String.Format("{0}{1}{2}{3}{4}", a, b, c, d, e)
+/- 1540ms


so in my opinion, only use string.format to do real formatting :-)
the difference between the first 2 seems strange to me
is this a compiler problem?
oh yes, everything was ran in debug mode in visual studio 2003...


dominique
 
* "Dominique Vandensteen said:
loop of 1.000.000 concatenations of 5 public string variables in a class
gave following results:

result = a & b & c & d & e
+/- 420ms

result = a
result &= b
result &= c
result &= d
result &= e
+/- 370ms
Click to expand...

Did you have a look at the IL generated by the compiler using the
"ILDASM.EXE" tool?
 
Dominique,
the difference between the first 2 seems strange to me
is this a compiler problem?
Click to expand...
No! It has to do with how the statements are created as IL!
result = a & b & c & d & e
Click to expand...
result = a
result &= b
result &= c
result &= d
result &= e
Click to expand...

Look at the generated IL (ILDASM.EXE). The first one is calling
String.Concat once with an ParamArray of Strings, so VB.NET needs to build
the array first. While the second is calling String.Concat with 2 arguments
4 times, no hidden array.

Try the same two tests with 4 values instead of 5:
result = a & b & c & d
Click to expand...
result = a
result &= b
result &= c
result &= d
Click to expand...

As String.Concat has 4 overloads: 2 strings, 3 strings, 4 strings, and
Paramarray. In your test, you gave 5 parameters which causes VB.NET to
choose the Paramarray overload, where as in the variation I just gave there
are only 4 parameters, so the 4 string overload will be picked... The
ParamArray is removed from the picture.
so in my opinion, only use string.format to do real formatting :-)
Click to expand...
Of course the definition of "real formatting" is subjective ;-))

I tend to consider "real formatting" as including string literals in
addition to other variables.

The other major reason to use String.Format is that you can read the format
string from a resource file, enabling Internationalization!

You can read the format from an embedded resx file via a ResourceManager. In
your app you can have a resx file for each spoken language you are deploying
your app to. The place holders in the format string have fixed numbers,
based on the parameters to the String.Format command, however their position
in the string can change.

Dim format As String
' format = read "v {0} w {1} x {2} y {3} z {4}"
' format = read "z {4} y {3} x {2} w {1} v {0}"
' format = read "w {1} x {2} z {4} v {0} y {3}"
Dim s As string
s = String.Format(format, a, b, c, d, e)

I rarely base choosing String.Format based on performance alone, unless that
routine has proven to be a performance problem with Profiling.

Note String.Format will be slower as it is overloaded with object
parameters, so any value types need to be boxed in order to call the method.
It can accept upto 3 object parameters before it uses the ParamArray
overload.

Hope this helps
Jay
 
Hi Dominique,

For me was the small discussion only about readability.

I think the string.format is for the ones who are used to it, and that is
not me, I have always to analyse it. I find a concatination of words better
to read than that.

In this kind of operations the speed differences are so small that we have
in my opinion to ignore them.

But thanks for your test, makes again a lot more clear for me.

Cor
 
Back
Top