Brian On Software

It’s really wonderful when you learn something new once in a while. As I was discussing with another .NET developer about the importance of knowing when to use constants and fields, he corrected me when I mistakenly told him that String.Empty was implemented as a constant.  In fact, if you look inside the String class, you’ll actually see that String.Empty is not implemented as a constant, but as a field (a static read-only field to be precise).

As I was thinking about the reason behind this, something hit me: I should be conscious of my decision whether I should use a constant or a field when dealing with strings.  The reason is simple: avoid unnecessary performance hits.  Take note that the only valid reference type for a constant is either string or null because you cannot instantiate a reference type in compile-time, which is when constants are evaluated.

I made a simple test to verify my little theory, since I couldn’t find a good answer for it on the Web. The test consist of a class that declares both a constant string and a static read-only string field. In its entry method, I call various methods which iterate a certain number of times (10, 100, 1000, 10 000 and 100 000) and use either the constant or the static read-only field respectively.  Here’s a sample code I used for this test:

class Program
{
  private const string Constant = "Constant";
  private static readonly string field = "field";

  private static void Main(string[] args)
  {
    // 10 iterations
    DoConstant10();
    DoField10();

    // 100 iterations
    DoConstant100();
    DoField100();

    // 1000 iterations
    DoConstant1000();
    DoField1000();

    // 10000 iterations
    DoConstant10000();
    DoField10000();

    // 100000 iterations
    DoConstant100000();
    DoField100000();
  }

  private static void DoField100000()
  {
    string s = string.Empty;
    for (int i = 0; i < 100000; i++)
	  s += field;
  }

  private static void DoConstant100000()
  {
    string s = string.Empty;
    for (int i = 0; i < 100000; i++)
	  s += Constant;
  }

  // And so on...
}

Next, I profiled the application with JetBrains DotTrace 3.1 (using the standard configuration options) and got the following results:

We clearly see that for the same iterations, using a string as field rather than a constant has almost a 2:1 performance improvement ratio over the latter.  Now, the title of the post is “Why you should use…” and not “Why you must use…” because there are some scenarios when using a string constant is better suited, such as when the constant is being used as a case in a switch statement (you cannot use a static readonly field as a case in a switch statement because its value will not be known until runtime).

Another thing you should be conscious of is relying on your experience rather than a tool’s recommendation. For example, when you declare a static read-only string variable, ReSharper will recommend you to transform it as a constant.  You shouldn’t always obey the tool unless you know exactly the tradeoffs and have considered the impact and risks associated with the decision.

Be a good judge over your codebase. Analyze the evidence and study the tradeoffs. There’s nothing like a good profiler to uncover the truths behind your code.