Probably most of you have already heard about string interning,  but if not, let me introduce this concept briefly.

When you application uses string frequently, and I’m 99,9% sure it does, then think about how much memory would be wasted if the same strings that appear in your application repeatedly had been memory allocated every time they are used? CLR has it’s remedy for that situation. Once the AppDomain is being loaded, CLR creates an internal hashtable which keys are the actual strings and values are pointed to the objects on the managed heap. This hashtable is initially empty, and is being populated with new string entries that come while the program executes.  This means that no longer duplicated string objects are created on the heap. You may wonder, “hey, but what if I modify one instance of that “grouped” string objects? Will it affect the strings in other places that just before a while were identical to the modified one? The answer is of course no. Remember that strings are immutable - which means that you are not allowed to modify the string instance (unless using unsafe operations). Once you “modify”  the string object, the new instance is created and returned under the hood and the previous instance is now ready to be GC-ed (of course the condition for this is that the “old” string was unique in the AppDomain).

When you are using the 2.0 version of the CLR (remember, please distinct the CLR versions from the .NET Framework versions) you should get the String Interning mechanism working  by default out of the box. However, there is some weirdness behind it.

Assemblies under CLR 2.0 are by default marked with the System.Runtime.CompilerServices.CompilationRelaxations.NoStringInterning flag value. According to what ECMA specification says, because of that the CLR may choose not to intern all of the strings defined in that assembly metadata.  That would seem that we have to control the interning mechanism by using the Intern or IsInterned methods manually. Finally, let me say that 2.0 version of the CLR ignores the mentioned flag that is produced by the C# compiler. Pretty confusing, isn’t it? All this mess is because the concerns about performance. By default, when an assembly is loaded  CLR interns all the strings that exist in an assembly’s metadata. This process can hurt the performance significantly, that is why Microsoft choosed to “turn this feature off” by default.

Concluding, you can design your CLR 2.0 applications with the string interning mechanism provided by default, so this code:

private static void Main(string[] args)

{

    string firstReference = “D’oh!”;

    string stillSameReference = “D’oh!”;

    // True – under CLR 2.0

    Console.WriteLine(ReferenceEquals(firstReference, stillSameReference)); 

}

This code snipped should be predictable under the CLR 2.0 and print “True” to the output. However, as Jeff Richter in his fantastic book explains, you should not rely on this mechanism and leverage string interning manually by using the appropriate methods (Intern, IsInterned) because we do not know how the next versions of the CLR will interpret the NoStringInterning flag.