445,898 Members | 2,012 Online
Need help? Post your question and get tips & solutions from a community of 445,898 IT Pros & Developers. It's quick & easy.

# declaration inside vs. outside the loop

 P: n/a 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 Feb 23 '07 #1
7 Replies

 P: n/a Gary Wessle wrote: 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 -- Please remove capital 'A's when replying by e-mail I do not respond to top-posted replies, please don't ask Feb 23 '07 #2

 P: n/a "Victor Bazarov"

 P: n/a Gary Wessle wrote: "Victor Bazarov" Gary Wessle wrote: >>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 onlybe different on a particular platform, with a particularcompiler.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. 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. Feb 23 '07 #4

 P: n/a Gary Wessle wrote: "Victor Bazarov" >Gary Wessle wrote: >>>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 onlybe different on a particular platform, with a particularcompiler.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. 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 Feb 23 '07 #5

 P: n/a Gary Wessle wrote: "Victor Bazarov" Gary Wessle wrote: >>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 onlybe different on a particular platform, with a particularcompiler.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. 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 -- Please remove capital 'A's when replying by e-mail I do not respond to top-posted replies, please don't ask Feb 23 '07 #6

 P: n/a > > 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 Feb 23 '07 #7

 P: n/a On Feb 23, 4:25 pm, John Harrison

### This discussion thread is closed

Replies have been disabled for this discussion.