Take the 2-minute tour ×

I've got a small piece of code that is parsing an index value to determine a cell input into Excel. It's got me thinking...

What's the difference between

xlsSheet.Write("C" + rowIndex.ToString(), null, title);


xlsSheet.Write(string.Format("C{0}", rowIndex), null, title);

Is one "better" than the other? And why?

share|improve this question
This is similar to stackoverflow.com/questions/16432/… –  Jonathan S. Nov 17 '08 at 23:06
possible duplicate of Why use String.Format? –  Druid Aug 2 '12 at 7:13
add comment

14 Answers

up vote 41 down vote accepted

To be honest, I think the first version is simpler - although I'd simplify it to:

xlsSheet.Write("C" + rowIndex, null, title);

I suspect other answers may talk about the performance hit, but to be honest it'll be minimal if present at all - and this concatenation version doesn't need to parse the format string.

Format strings are great for purposes of localisation etc, but in a case like this concatenation is simpler and works just as well.

share|improve this answer
Boxinggggggggggg.........., you're culpable Mr. Skeet! :) –  nawfal May 12 '13 at 8:49
@nawfal: See msmvps.com/blogs/jon_skeet/archive/2008/10/08/… –  Jon Skeet May 12 '13 at 11:09
I know I know. It was made in jest (have read the link btw before, which was a good read) –  nawfal May 12 '13 at 11:24
Jon. I've always been a fan of Mr. Richter, and have followed guidance on boxing etc. religiously. However, after reading your (old) article, I am now a convert. Thanks –  stevethethread Jan 21 at 14:42
add comment

My initial preference (coming from a C++ background) was for String.Format. I dropped this later on due to the following reasons:

  • String concatenation is arguably "safer". It happened to me (and I've seen it happen to several other developers) to remove a parameter, or mess up the parameter order by mistake. The compiler will not check the parameters against the format string and you end up with a runtime error (that is, if you're lucky enough not to have it in an obscure method, such as logging an error). With concatenation, removing a parameter is less error prone. You could argue the chance of error is very small, but it may happen.

- String concatenation allows for null values, String.Format does not. Writing "s1 + null + s2" does not break, it just treats the null value as String.Empty. Well, this may depend on your specific scenario - there are cases where you'd like an error instead of silently ignoring a null FirstName. However even in this situation I personally prefer checking for nulls myself and throwing specific errors instead of the standard ArgumentNullException I get from String.Format.

  • String concatenation performs better. Some of the posts above already mention this (without actually explaining why, which determined me to write this post :).

Idea is the .NET compiler is smart enough to convert this piece of code:

public static string Test(string s1, int i2, int i3, int i4, 
        string s5, string s6, float f7, float f8)
    return s1 + " " + i2 + i3 + i4 + " ddd " + s5 + s6 + f7 + f8;

to this:

            string s5, string s6, float f7, float f8)
    return string.Concat(new object[] { s1, " ", i2, i3, i4, 
                    " ddd ", s5, s6, f7, f8 });

What happens under the hood of String.Concat is easy to guess (use Reflector). The objects in the array get converted to their string via ToString(). Then the total length is computed and only one string allocated (with the total length). Finally, each string is copied into the resulting string via wstrcpy in some unsafe piece of code.

Reasons String.Concat is way faster? Well, we can all have a look what String.Format is doing - you'll be surprised at the amount of code required to process the format string. On top of this (I've seen comments regarding the memory consumption), String.Format uses a StringBuilder internally. Here's how:


So for every passed argument, it reserves 8 characters. If the argument is a one-digit value, then too bad, we have some wasted space. If the argument is a custom object returning some long text on ToString(), then there might be even some reallocation needed (worst-case scenario, of course).

Compared to this, the concatenation only wastes the space of the object array (not too much, taking into account it's an array of references). There's no parsing for format specifiers and no intermediary StringBuilder. The boxing/unboxing overhead is present in both methods.

The only reason I'd go for String.Format is when localization is involved. Putting format strings in resources allows you to support different languages without messing with the code (think about scenarios where formatted values change order depending on the language, i.e. "after {0} hours and {1} minutes" may look quite different in Japanese :).

To sum up my first (and quite long) post:

  • best way (in terms of performance vs. maintainability/readability) for me is using string concatenation, without any ToString() calls
  • if you're after performance, make the ToString() calls yourself to avoid boxing (I'm somewhat biased towards readability) - same as first option in your question
  • if you're showing localized strings to the user (not the case here), String.Format() has an edge.
share|improve this answer
1) string.Format is "safe" when using ReSharper; that is, it is as safe as any other code that can be used [incorrectly]. 2) string.Format does allow for a "safe" null: string.Format("A{0}B", (string)null) results in "AB". 3) I seldom care about this level of performance (and to that end, it is a rare day when I pull out StringBuilder)... –  user166390 Mar 19 '12 at 22:46
Agree on 2), I will edit the post. Can't verify if this was safe back in 1.1, but the latest framework is indeed null-safe. –  Dan C. Mar 20 '12 at 9:27
Is string.Concat still used if one of the operands is a method call with a return value, rather than being a parameter or variable? –  Richard Collette Jan 14 '13 at 15:26
@RichardCollette Yes, String.Concat is used even of you concatenate return values of method calls, e.g. string s = "This " + MyMethod(arg) + " is a test"; gets compiled to a String.Concat() call in Release mode. –  Dan C. Jan 22 '13 at 18:29
add comment

I think this MSDN link is a reasonable summary. Jon Skeet also has a interesting blog entry on the subject

share|improve this answer
He also has an interesting post up above ;) –  Joel Coehoorn Nov 17 '08 at 21:40
His answer isn't as good as his blog entry. Actually, Jon and I ought to get together for a drink, as I believe we live in the same city :-) –  RoadWarrior Nov 17 '08 at 21:44
Skeet vs. Skeet for the best answer! Who will win?? –  Jonathan S. Nov 17 '08 at 23:04
add comment

I think the first option is more readable and that should be your primary concern.


string.Format uses a StringBuilder under the hood (check with reflector) so it won't have any performance benefit unless you are doing a significant amount of concatenation. It will be slower for your scenario but the reality is this micro performance optimisation decision is inappropriate most of the time and you should really be focusing on the readability of your code unless you are in a loop.

Either way, write for readability first and then use a performance profiler to identify your hotspots if you really think you have performance concerns.

share|improve this answer
add comment

If your string was more complex with many variables being concatenated, then I would choose the string.Format(). But for the size of string and number of variables being concatenated in your case, I'd go with your first version, it's more spartan.

share|improve this answer
add comment

For a simple case where it's a simple single concatenation, I feel that it's not worth the complexity of string.Format (and I haven't tested, but I suspect that for a simple case like this, string.Format might be slightly slower, what with the format string parsing and all). Like Jon Skeet, I prefer to not explicitly call .ToString(), since that will be done implicitly by the string.Concat(string, object) overload, and I think the code is cleaner-looking and easier to read without it.

But for more than a few concatenations (how many is subjective), I definitely prefer string.Format. At a certain point I think that both readability and performance suffer unnecessarily with concatenation.

If there are many parameters to the format string (again, "many" is subjective), I usually prefer to include commented indices on the replacement arguments, lest I lose track of which value goes to which parameter. A contrived example:

    "Dear {0} {1},\n\n" +

    "Our records indicate that your {2}, \"{3}\", is due for {4} {5} shots.\n" +
    "Please call our office at 1-900-382-5633 to make an appointment.\n\n" +

    "Thank you,\n" +
    "Eastern Vetinary",

    /*4*/client.Pet.Gender == Gender.Male ? "his" : "her",
share|improve this answer
fyi, you can use @"...multi line string " instead of all the concatenations. –  Aaron Palmer Nov 18 '08 at 13:48
Yes, but then you have to left-justify your string. @ strings include all new lines and tab characters between the quotes. –  P Daddy Nov 18 '08 at 14:10
I know this is old, but this is a case where I'd say put the format string in a resx file. –  Andy Mar 21 '12 at 2:30
Wow, everybody's focused on the string literal, instead of the heart of the matter. –  P Daddy Mar 21 '12 at 2:52
add comment

That example is probably too trivial to notice a difference. In fact, I think in most cases the compiler can optimize away any difference at all.

However, if I had to guess I'd give string.Format() an edge for more complicated scenarios. But that's more of a gut feeling that's it's likely to do a better job utilizing a buffer instead of producing multiple immutable strings, and not based on any real data.

share|improve this answer
add comment

I like String.Format because can make your formatted text much easier to follow and read than inline concatenation, also its much more flexible allowing you to format your parameters, however for short uses like yours I see no problem about concatenating.

For concatenations inside loops or in big strings you should always try to use the StringBuilder class.

share|improve this answer
add comment

I have taken a look at String.Format (using Reflector) and it actually creates a StringBuilder then calls AppendFormat on it. So it is quicker than concat for multiple stirngs. Quickest (I believe) would be creating a StringBuilder and doing the calls to Append manually. Of course the number of "many" is up for guessing. I would use + (actually & becuase I am a VB programmer mostly) for something as simple as your example. As it gets more complex I use String.Format. If there are LOTS of variables then I would go for a StringBuilder and Append, for example, we have code that builds code, there I use one line of actual code to output one line of generated code.

There seems to be some speculation about how many strings get created for each of these operations, so lets take a few simple examples.

"C" + rowIndex.ToString();

"C" is already a string.
rowIndex.ToString() creates another string. (@manohard - no boxing of rowIndex will occur)
Then we get the final string.
If we take the example of


then we have "C{0}" as a string
rowIndex gets boxed to be passed to the function
A new stringbuilder is created
AppendFormat is called on the string builder - I don't know the details of how AppendFormat functions but lets assume it is ultra efficient, it is still going to have to convert the boxed rowIndex into a string.
Then convert the stringbuilder into a new string.
I know that StringBuilders attempt to prevent pointless memory copies from taking place but the String.Format still ends up with extra overhead compared to the plain concatenation.

If we now take an example with a few more strings

"a" + rowIndex.ToString() + "b" + colIndex.ToString() + "c" + zIndex.ToString();

we have 6 strings to start with, which will be the same for all cases.
Using concatenation we also have 4 intermediate strings plus the final result. It is those intermediate results that are eliminated by using String,Format (or a StringBuilder).
Remember that to create each intermediate string, the previous one must be copied to a new memory location, it is not just the memory allocation that is potentially slow.

share|improve this answer
Nitpick. In the "a" + ... + "b" + ... + "c" + ..., you won't actually have 4 intermediate strings. The compiler will generate a call to the String.Concat(params string[] values) static method, and they'll all be concatenated at once. I'd still prefer string.Format for readability's sake, though. –  P Daddy Nov 19 '08 at 1:08
add comment

String concatenation takes more memory compared to String.Format. So best way to concatenate strings is using String.Format or System.Text.StringBuilder Object.

Let's take first case: "C" + rowIndex.ToString() Let's assume rowIndex is a value type so ToString() method has to Box to convert the value to String and then CLR creates memory for the new string with both values included.

Where as string.Format expects object parameter and takes in rowIndex as an object and converts it to string internally offcourse there will be Boxing but it's intrinsic and also it's won't take up as much memory as in first case.

For short strings it won't matter that much I guess...

share|improve this answer
add comment

string.Format is probably a better choice when the format template ("C{0}") is stored in a configuration file (such as Web.config / App.config)

share|improve this answer
add comment

I did a bit of profiling of various string methods including string.Format, StringBuilder and string concatenation. String concatenation almost always outperformed the other methods of building strings. So, if performance is key, then its better. However, if performance is not critical then I personally find string.Format to be easier to follow in code. (But that's a subjective reason) StringBuilder however, is probably most efficient with respect to memory utilization.

share|improve this answer
add comment

I prefer String.Format regarding to performance

share|improve this answer
add comment

I agree with alot of points above, another point that I believe should be mentioned is code maintainability. string.Format allows for easier changing of code.

i.e. I have a message "The user is not authorized for location " + location or "The User is not authorized for location {0}"

if I ever wanted to change the message to say: location + " does not allow this User Access" or "{0} does not allow this User Access"

with string.Format all I have to do is change the string. for concatenation I have to modify that message

if used in multiple places can save allot of time.

share|improve this answer
add comment

Your Answer


