Reference type variable recycling - is a new reference variable created every loop in a loop if declared therein?

后端 未结 3 1960
梦谈多话
梦谈多话 2020-11-28 07:54

Is the following:

MyObject myVariable;
for(int i = 0; i < objects.Length, i++){
  myVariable = objects[i];
  // do stuff...
}

more effic

相关标签:
3条回答
  • 2020-11-28 08:31

    No, "variables" exist almost entirely for the sake of the programmer. You're not creating any additional work at run-time by declaring the variable inside the method.

    In theory, the compiler will set aside space on the stack when a method is called for each variable declared in that method. So the presence of that variable in the method would be more important than its scope. No space is allocated on the heap unless the new keyword is used.

    In practice, the compiler can identify variables that have such a short scope that they can be stored in a register on the CPU instead of needing space on the stack. For example:

    var a = b[c];
    a.ToString();
    // never access "a" again.
    

    ... would be the same as:

    b[c].ToString();
    

    ... because the compiler recognizes that it only needs to store the result of b[c] long enough to call a method on it, so it can just use a CPU register instead of using memory.

    For this reason, declaring your variable inside the loop could actually cause the method to allocate less stack space for the variable, depending on the possible logic flow afterward. However, that gets into huge micro-optimization that doesn't make any sense for most people to care about.

    Update

    Since some people still seem to think that declaring a variable in a loop has some effect, I guess I need to provide proof. Type the following programs into LINQPad.

    int j;
    for(int i = 0; i < 5; i++)
    {
        j = i;
    }
    

    ... and...

    for(int i = 0; i < 5; i++)
    {
        int j = i;
    }
    

    Execute the code, then go to the IL tab to see the generated IL code. It's the same for both of these programs:

    IL_0000:  ldc.i4.0    
    IL_0001:  stloc.0     
    IL_0002:  br.s        IL_0008
    IL_0004:  ldloc.0     
    IL_0005:  ldc.i4.1    
    IL_0006:  add         
    IL_0007:  stloc.0     
    IL_0008:  ldloc.0     
    IL_0009:  ldc.i4.5    
    IL_000A:  blt.s       IL_0004
    

    So there's incontrovertible proof that this will make no difference at compile time. You'll get exactly the same compiled IL from both programs.

    0 讨论(0)
  • 2020-11-28 08:37

    I did Benchmark the "Problem" and agree with StriplingWarrior. At least it makes no difference in terms of speed.

    long start = Time();
    long end = Time();
    Console.WriteLine("Benchmark Runtime: " + (end - start) + " Microseconds");
    
    for(int k = 0; k < 5; k++)
    {
        start = Time();
        int j;
        for (int i = 0; i < 900000000; i++)
        {
            j = i;
        }
        end = Time();
        Console.WriteLine("Benchmark 1: " + (end - start) + " Microseconds");
    }
    
    for (int k = 0; k < 5; k++)
    {
        start = Time();
        for (int i = 0; i < 900000000; i++)
        {
            int j = i;
        }
        end = Time();
        Console.WriteLine("Benchmark 2: " + (end - start) + " Microseconds");
    }
    

    Results:

    Benchmark Runtime: 1 Microseconds
    Benchmark 1: 1730816 Microseconds
    Benchmark 1: 1725885 Microseconds
    Benchmark 1: 1725629 Microseconds
    Benchmark 1: 1726052 Microseconds
    Benchmark 1: 1726121 Microseconds
    Benchmark 2: 1725843 Microseconds
    Benchmark 2: 1725576 Microseconds
    Benchmark 2: 1726233 Microseconds
    Benchmark 2: 1725786 Microseconds
    Benchmark 2: 1729965 Microseconds
    
    0 讨论(0)
  • 2020-11-28 08:41

    short answer, yes.

    long answer, yes it is faster, but hardly noticeable unless repeated many times. :-)

    I am not sure if the compiler will optimize it or not, I doubt it though, and if it does, good for it, you should still write it as if it doesn't, make it a habbit.

    0 讨论(0)
提交回复
热议问题