4

Possible Duplicate:
Difference between declaring variables before or in loop?

I always wondered, is it faster to do like this:

int i;

for (i=0;i<...)
for (i=0;i<...)
for (i=0;i<...)
for (i=0;i<...)

or

for (int i=0;i<...)
for (int i=0;i<...)
for (int i=0;i<...)
for (int i=0;i<...)

Meaning, if i have multiple for loops in one function, does it work faster if i declare loop iteration variable once and use it multiple times, or declare it inside each for loop?

Community
  • 1
  • 1
Istrebitel
  • 2,963
  • 6
  • 34
  • 49
  • 10
    It's not a matter of "what's faster", it's about reducing the scope of your variable to the minimum necessary. As a programmer, there are more important considerations than such "optimizations". – spender Apr 27 '12 at 08:46
  • Did you test it? Always measure before optimizing tiny things like this. I bet that the thing you are doing inside the loop can be optimized more than the i – Emond Apr 27 '12 at 08:47
  • Yes those are valid concerns but since i'm a kind of self-taught i just wanted to know if its a common sense to do it one way or another and maybe i'm doing it wrong – Istrebitel Apr 27 '12 at 09:05
  • You are taking premature optimization to a new level. If you are doing any meaningful work in the loop, neither approach will have material effect on your program execution time. Profile first and then optimize. – SolutionYogi Apr 27 '12 at 15:01

4 Answers4

4

The IL generated will be (for release build) pretty much identical for both approaches.

Consider this code:

static int test1()
{
    int result = 0;
    int i;

    for (i = 0; i < 10; ++i)
        ++result;

    for (i = 0; i < 10; ++i)
        ++result;

    return result;
}

static int test2()
{
    int result = 0;

    for (int i = 0; i < 10; ++i)
        ++result;

    for (int i = 0; i < 10; ++i)
        ++result;

    return result;
}

This generates the following IL for a release build, which I have placed side-by-side for easier comparison:

test1():                        test2()
{                               {
    .maxstack 2                     .maxstack 2
    .locals init (                  .locals init (
        [0] int32 result,               [0] int32 result,
        [1] int32 i)                    [1] int32 i,
                                        [2] int32 V_2)
    L_0000: ldc.i4.0                L_0000: ldc.i4.0 
    L_0001: stloc.0                 L_0001: stloc.0 
    L_0002: ldc.i4.0                L_0002: ldc.i4.0 
    L_0003: stloc.1                 L_0003: stloc.1 
    L_0004: br.s L_000e             L_0004: br.s L_000e
    L_0006: ldloc.0                 L_0006: ldloc.0 
    L_0007: ldc.i4.1                L_0007: ldc.i4.1 
    L_0008: add                     L_0008: add 
    L_0009: stloc.0                 L_0009: stloc.0 
    L_000a: ldloc.1                 L_000a: ldloc.1 
    L_000b: ldc.i4.1                L_000b: ldc.i4.1 
    L_000c: add                     L_000c: add 
    L_000d: stloc.1                 L_000d: stloc.1 
    L_000e: ldloc.1                 L_000e: ldloc.1 
    L_000f: ldc.i4.s 10             L_000f: ldc.i4.s 10
    L_0011: blt.s L_0006            L_0011: blt.s L_0006
    L_0013: ldc.i4.0                L_0013: ldc.i4.0 
    L_0014: stloc.1                 L_0014: stloc.2 
    L_0015: br.s L_001f             L_0015: br.s L_001f
    L_0017: ldloc.0                 L_0017: ldloc.0 
    L_0018: ldc.i4.1                L_0018: ldc.i4.1 
    L_0019: add                     L_0019: add 
    L_001a: stloc.0                 L_001a: stloc.0 
    L_001b: ldloc.1                 L_001b: ldloc.2 
    L_001c: ldc.i4.1                L_001c: ldc.i4.1 
    L_001d: add                     L_001d: add 
    L_001e: stloc.1                 L_001e: stloc.2 
    L_001f: ldloc.1                 L_001f: ldloc.2 
    L_0020: ldc.i4.s 10             L_0020: ldc.i4.s 10
    L_0022: blt.s L_0017            L_0022: blt.s L_0017
    L_0024: ldloc.0                 L_0024: ldloc.0 
    L_0025: ret                     L_0025: ret 
}                               }

This makes it pretty clear that you should choose the version where 'i' is local to the loop, because that's better practice.

However, the version with the loop counter declared outside the loops will be faster by the amount of time needed to initialise an int to zero - pretty much negligible.

Matthew Watson
  • 104,400
  • 10
  • 158
  • 276
3

In theory the former should be faster, because there is only one memory location, which is reused.

Petar Ivanov
  • 91,536
  • 11
  • 82
  • 95
  • Not true. The IL is almost the same for both approaches. – Matthew Watson Apr 27 '12 at 09:09
  • well, it's not - I used dotPeek to dissassemble both versions and they were different. The only way to be the same would be if there is a compiler optimization, but in this case that's not what happened. – Petar Ivanov Apr 27 '12 at 09:10
  • Please look at the IL code I posted below. It's pretty much identical between the two approaches. The only overhead for declaring 'i' locally to the loops is a single .init at the start of the function. Were you perhaps looking at the debug build? – Matthew Watson Apr 27 '12 at 09:16
  • Well, as you can see in the IL posted, there is almost no difference. I also checked the debug build, and for that there is no difference at all. – Matthew Watson Apr 27 '12 at 09:18
  • how do you look at the IL, btw? – Petar Ivanov Apr 27 '12 at 09:19
1

As spender mentioned there's no speed issue concerned here it's more to do with the scope you need the variable available in. If it only needs to be available only in the loop then declare it in the loop not outside it. But yes the first approach is faster if you need it available to all the loops.

ranjez
  • 329
  • 3
  • 13
0

The two codes produce same JITted code. So, it really doesn't have any performance gain.

orlupo
  • 46
  • 1