String.Empty vs. ""

Throughout my MS.NET years I was occasionally asked about differences between C# String.Empty and the empty string literal (""). And also when implementing C# and .NET coding-style documents this has always been challenging since everybody has his own opinion, experience, and taste.
A) string s1 = String.Empty;
B) string s2 = "";
Here’s some advice which might come handy:
Performance
String.Empty is a static read-only public field which is initialised by the static constructor of the String class. Simplified MSIL code generated for statement A is ldsfld String.Empty; this simply pushes the reference of a specific field (String.Empty in this case) into local stack of your executing method after invoking static constructor of the class if not previously executed – this is a 5 bytes instruction though. Note that String.Empty field actually assigns the empty literal ("") to a static field only once and during first access to the String class and this is no big deal; then the resulting reference to constant "" value (from string pool - see below) will be reused for your application domain lifetime (your windows process whatever it is, your hosting environment whatever it is…)
On the other hand, the C# statement B results into ldstr "" MSIL statement; again a 5 bytes instruction. ldstr pushes the supplied literal into AppDomain's internal string pool (CLR internal GlobalStringLiteralMap C++ class) if not previously loaded into the map. The reason is obvious: more efficient memory usage by sharing string literals in memory - a technique called string interning.
When comparing the two alternatives, statement A is so straightforward in CLR implementation making it simple and fast, whilst statement B goes through the overhead of checking the AppDomain's string pool (an internal hash-table) bringing very small performance penalty. BUT:

1. A and B have JIT compile-time differences and JIT-Compiler will eventually generate nearly same results in either cases; this also implies there is absolutely no performance penalty when your assembly [not framework assemblies] is NGENed (using ngen.exe for example)
2. During JIT-compilation of your executing method there is this very small (nearly zero) performance penalty which is paid only once. In other words, worrying about performance differences between statement A and B is pointless.

Coding Style
Well, whenever it comes to developing an effective coding-style document, I've realised we're not only talking about technology and it also involves aesthetics and human nature! I suppose we all do agree that increasing readability to at least reduce maintenance costs is a generally accepted coding-style design measure; this may hardly become a baseline for coding-style challenges.
What I'll say here, is only my personal opinion and favourite syntax supported by 16+ years of extensive coding effort - yet it does not necessarily reflect community preference: the String.Empty syntax usually results into higher readability by adding distinctness compared to the "" syntax. I'll definitely go for the first one as I feel more comfortable when reviewing and skimming someone else’s code. The "" syntax is not visually clear enough [needs more attention to see whether or not spaces are contained - could make eyes fatigued for very lengthy code]. Also, it is not clear with non-fixed-size fonts where the number of involved spaces matters [in very rare cases – like when using spaces for print or control alignments]. This is because these fonts usually have narrowed space characters not appropriate for extensive coding.

Technorati Tags: C#,.NET,Microsoft,CLR,String Interning