Does instantiation of local string variable impact performance?

Question

I have two situations:

    static void CreateCopyOfString()
    {
        string s = "Hello";
        ProcessString(s);
    }

and

    static void DoNotCreateCopyOfString()
    {
        ProcessString("Hello");
    }

The IL for these two situations looks like this:

    .method private hidebysig static void  CreateCopyOfString() cil managed
    {
        // Code size       15 (0xf)
        .maxstack  1
        .locals init ([0] string s)
        IL_0000:  nop
        IL_0001:  ldstr      "Hello"
        IL_0006:  stloc.0
        IL_0007:  ldloc.0
        IL_0008:  call       void ConsoleApplication1.Program::ProcessString(string)
        IL_000d:  nop
        IL_000e:  ret
    } // end of method Program::CreateCopyOfString

and

    .method private hidebysig static void  DoNotCreateCopyOfString() cil managed
    {
          // Code size       13 (0xd)
          .maxstack  8
          IL_0000:  nop
          IL_0001:  ldstr      "Hello"
          IL_0006:  call       void ConsoleApplication1.Program::ProcessString(string)
          IL_000b:  nop
          IL_000c:  ret
    } // end of method Program::DoNotCreateCopyOfString

In the first case, there is extra calls for string init, stloc.0 and ldloc.0. Does this mean that the first case would perform weaker than the second case where the string is directly passed to the method instead of first storing it in the local variable?

I saw the question Does initialization of local variable with null impacts performance? but it seems to be little bit different than what I need to know here. Thanks.

How did you compiled the code? Was it in Debug or Release mode? I believe, that in Release both IL would look exactly the same. — MarcinJuraszek

Jon Skeet Jon Skeet · Accepted Answer · 2013-03-22T20:58:56

You're looking at the unoptimized IL, for one thing - hence all the "nop"s. You may find it generates different code when building the Release version.

Even with the unoptimized version, if you're running under an optimizing JIT, I'd expect it to end up with the same JITted code.

Even with a non-optimizing JIT which did actually generate code which did more work each time this is called, I'd be staggered to see this have a significant impact in any real application.

As ever:

Set performance goals before you start, and measure against them.
Work out which decisions will be hard to fix later in terms of performance, and worry about those much more than decisions like this, which can be changed later with no impact elsewhere.
Write the most simplest, most readable code that will work first.
If that doesn't perform well enough, investigate whether making changes which harm readability help performance enough to warrant the pain.

Does instantiation of local string variable impact performance?

2 Answers