C# “” better than string.Empty?
I recently read an article that argued that “” is “Better than String.Empty”
The argument is that since string.Empty doesn’t work in all situations, we should not use it at all. He further argues that since the compiler can’t optimize code using string.Empty, the performance gains we might lose due to our lack of this optimization further supports the argument that we should not use it at all.
But at what price?
First, it is impressive that he took the time to evaluate the performance hit that using String.Empty can cause. I’m pretty sure his evaluation of using String.Empty in a case statement is from his attempt to do so only to find out he couldn’t.
However, he seems to have overlooked the price of not using String.Empty. Certainly, Microsoft didn’t put that there without thinking about what they were doing.
So let’s further evaluate what is happening in our code when we use “” rather than using String.Empty.
Consider Real World Optimization
In the article referenced, he does one, and only one, bench mark to prove that “” is faster than String.Empty by putting the code in a loop that could be optimized out.
if (string.Empty == null) { throw new Exception(); }
vs
if ("" == null) { throw new Exception(); }
But what about a real world scenario where the code is NOT optimized out?
String s = String.Empty;
vs
String x = "";
In my test, there was no noticeable difference. Sometimes string.Empty was faster and sometimes the empty string was faster. And I expect the reason they are about the same is because the compiler optimized out the assignment.
In real life, I would expect String.Empty to take just slightly longer. But not enough to make it worth worrying about.
Consider String Comparison Cost
Second, string comparisons are notoriously expensive in every language I’ve ever worked in. Including the .NET languages. Instead of arguing that we can’t using String.Empty in a case statement, we would do better to argue that using a string in a case statement is the last of the possible alternatives we might use.
When evaluating for the empty string, for example, you might check the string’s length rather than checking the string itself. For other strings, you might check the first character of the string.
Writing Code is About Solving Problems
When I started my career, computers were slow and had a limited amount of memory. Writing the smallest amount of code that performed in the most efficient way was half the struggle of writing the application.
Today, neither of those issues are of primary concern. The first order of concern is to write an application that works. Once it is DOING what it is supposed to do, IF there are performance issues, we should do proper code evaluation to determine where the performance bottlenecks are and then, and only then, should we optimize our code for performance.
Generally, using String.Empty will serve you better than using “”. In the cases where String.Empty will not work either because of the code evaluation OR because of the performance considerations, yes, use “” instead. But, do it because there is a supportable reason, not because you think it may produce faster code.
In fact, I would argue that if your code has performance problems, the last place you should be looking is at this issue. You’ll get negligible gains. Your real problem is more likely in file IO, including database access and network access.
Other post in Advanced CSharp
- Two Interfaces. Same Method. Two meanings. - September 29th, 2008
- Making values nullable - October 9th, 2008
- CSharp's Property Shortcuts - October 23rd, 2008
- Readonly variables in CSharp? Really?! - October 29th, 2008
- Dispose with Using - November 10th, 2008
- Delegates in .NET - December 4th, 2008
- Using Sealed in CSharp - December 8th, 2008
- CSharp checked and unchecked - December 11th, 2008
- Advanced CSharp - unsafe mode - December 15th, 2008
- Volatile variables and CSharp threads - December 22nd, 2008
- What is the global keyword in CSharp? - December 29th, 2008
- CSharp fixed keyword - January 5th, 2009
- using - There's more there than you are using - February 2nd, 2009
- Stackalloc in CSharp - February 16th, 2009
- Removing Warnings from CSharp Compile Cycle - March 10th, 2009
- && vs & and | vs ||... What's the difference? - March 16th, 2009
- Advanced CSharp - yield - March 25th, 2009
- Just say “No!” to C# Regions? Really?! - April 16th, 2009
- C# “” better than string.Empty? - April 20th, 2009
- .Net String Pool – Not Just For The Compiler - April 22nd, 2009
- CSharp ?? Operator - May 18th, 2009
- Using VB.NET From CSharp - July 1st, 2009
- Dispose, Finalize and SuppressFinalize - July 9th, 2009
- What is .NET’s Object.GetHashCode() Used For? - August 5th, 2009
- ASP.NET Substitution Control - October 22nd, 2009
Other Related Items:
You Are EmptyYou Are EmptyPCExperience an alternative approach to the history of the late 1950's in the Soviet Union. In an alternate universe where Soviet Scienti... Read More >
The Pink Panther Classic Cartoon CollectionA complete collection of all 124 Pink Panther cartoons.Genre: Children's Video
Rating: NR
Release Date: 31-JAN-2006
Media Type: DVD
The Return of Sherlock Holmes - The Empty House [VHS]Did Sherlock Holmes survive his apparent demise at the hands of Professor Moriarty in The Final Problem? Clearly so, as his resurrection three years l... Read More >










The biggest thing for me is intent – when I see String.Empty I *know* the intent was to have an empty string.
And along the lines of your object-creation cost – we need to remember that C# strings are immutable. Even if we started with
string val = “”;
Any concatenation or modification of that string produces a new object anyway:
val = val + “some content here”;
So not only did you create a new instance of a string object when you created your empty string, but you don’t even get to “reuse” it.
Right, I said that.