declaration inside vs. outside the loop

[Gary Wessle]

Hi

which version is most efficient in principle?

****************
int res;
for( int i=0; i < 10000; i++ )
{
res = i * 5;
// do somethings.
}
***************
for( int i=0; i < 10000; i++ )
{
int res = i * 5;
// do somethings.
}
****************


thanks

 

[Victor Bazarov]

which version is most efficient in principle?

****************
int res;
for( int i=0; i < 10000; i++ )
{
res = i * 5;
// do somethings.
}
***************
for( int i=0; i < 10000; i++ )
{
int res = i * 5;
// do somethings.
}
****************

Neither. They are equivalent, in principle. They can only
be different on a particular platform, with a particular
compiler.

V

 

[Gary Wessle]

Neither. They are equivalent, in principle. They can only
be different on a particular platform, with a particular
compiler.

V

I was under the impression that inside the loop, each time you have an
the compiler looks to locate some memory to use,
vs. outside it only assigns the value to the same location.

 

[Mark P]

I was under the impression that inside the loop, each time you have an
the compiler looks to locate some memory to use,
vs. outside it only assigns the value to the same location.

Victor's point is that everything you've just discussed is
implementation dependent. Modern compilers are very good at
optimizing-- probably better than the average human on average. Likely
it makes no difference which version you use but if you really want to
know you have to test it. And you may be surprised.

 

[John Harrison]

I was under the impression that inside the loop, each time you have an
the compiler looks to locate some memory to use,
vs. outside it only assigns the value to the same location.

Your impression was wrong. The compiler can do what the hell it likes as
long as the program runs correctly. Allocating all necessary memory at
the start of a function, instead of allocating it bit by bit, is a
completely standard compiler optimization.

I know its hard because you're a newbie, but try and concetrate on
writing logical, comprehendable code, instead of worrying about whether
one way of doing things is a few microseconds faster than other. The
sooner you start to think about what is really important the quicker you
will become a good programmer.

john

 

[Victor Bazarov]

I was under the impression that inside the loop, each time you have an
the compiler looks to locate some memory to use,
vs. outside it only assigns the value to the same location.

There is no specified performance requirement for locating "some memory
to use", so, theoretically, it either happens in no time or there is no
way to figure out the difference between the two cases.

Practically, it is possible that if 'do somethings' is not very complex,
'res' can be stored in a register (in both cases) while the loop body is
executing. The former case requires the value to survive beyond the
loop, the latter doesn't. That only requires the storage to be updated
when exiting the loop (since you didn't declare 'res' volatile). I
strongly doubt that modern compilers would produce the code that would
allocate the necessary memory from the stack (the usual place for all
automatic objects) on every loop and deallocate it at the end. Even if
'res' were a UDT instance, memory allocation is likely to happen only
once.

I thought there was actually a FAQ entry about this. Isn't there?

V

 

[John Harrison]

Your impression was wrong. The compiler can do what the hell it likes as
long as the program runs correctly. Allocating all necessary memory at
the start of a function, instead of allocating it bit by bit, is a
completely standard compiler optimization.

In fact you can actually save memory by declaring variables inside
loops. Look at this code with variables outside the loops

void func()
{
int a, b;
for (int i = 0; i < 10; ++i)
{
a = something();
// do something with a
}
for (int i = 0; i < 10; ++i)
{
b = something();
// do something with b
}
}

or this code with them inside

void func()
{
for (int i = 0; i < 10; ++i)
{
int a = something();
// do something with a
}
for (int i = 0; i < 10; ++i)
{
int b = something();
// do something with b
}
}

I would not be surprised for a compiler to produce more efficent code
with the second version. The reason is that the the same memory location
can be reused for both variables a and b because they are never in use
at the same time. But the compiler has a much easier job of figuring
that out in the second case, because the declarations inside the loop
tell the compiler that the two variable cannot *possibly* be needed at
the same time.

I hope this example convinces you that it's the compiler's job to figure
out these kinds of micro-optimisations, not yours.

john

 

[robertwessel2]

In fact you can actually save memory by declaring variables inside
loops. Look at this code with variables outside the loops

void func()
{
int a, b;
for (int i = 0; i < 10; ++i)
{
a = something();
// do something with a
}
for (int i = 0; i < 10; ++i)
{
b = something();
// do something with b
}

}

or this code with them inside

void func()
{
for (int i = 0; i < 10; ++i)
{
int a = something();
// do something with a
}
for (int i = 0; i < 10; ++i)
{
int b = something();
// do something with b
}

}

I would not be surprised for a compiler to produce more efficent code
with the second version. The reason is that the the same memory location
can be reused for both variables a and b because they are never in use
at the same time. But the compiler has a much easier job of figuring
that out in the second case, because the declarations inside the loop
tell the compiler that the two variable cannot *possibly* be needed at
the same time.

I hope this example convinces you that it's the compiler's job to figure
out these kinds of micro-optimisations, not yours.

Nor should be surprised to discover that the compiler figures out that
the first version doesn't need physical space for both a and b either,
since b is (apparently) never used before a goes dead. Or that the
compiler also figures out that it has a register to hold a/b, and
never allocates any memory for it at all.