Variable waste

[mirhagk]

This relates to C# with .NET mostly, but I believe it is also relevant with c++.

Everyone always says use local variables, but for something like

[syntax="c++"]
for(int i=0;i<100;i++)
for(int p=0;p<100;p++)
//do something
[/syntax]

That would mean it allocates 400 bytes of data just to be wasted. Might not seem like alot, but in a 60 fps game that means 24 kb (approx) of memory being allocated every second. Now does the compiler see this and optimize it? Even without the p variable, the i still is unneccassary allocation. Wouldn't it just be better to declare some global variable called i, (and maybe one called p) and simply set them to 0 every time.

Now is this me just being paranoid or something, or is this actually a pretty sizeable optimization?

[Tony]

Leave such optimizations for the compiler to figure out; it almost always does a better job. The "optimizations" we need to worry about are picking out or designing the right algorithms.

[OneOffDriveByPoster]

mirhagk @ Sat Jan 01, 2011 10:51 pm wrote:

Now is this me just being paranoid or something, or is this actually a pretty sizeable optimization?

I think there is some confusion here as to how "automatic" variables are allocated. There is only space for one "i" and one "p" used here. The same space is used for each iteration of the loop.

[Tony]

Indeed.

Quote:

~ $ cat test.cpp
#include <iostream>

int main(){
for (int i=0; i<2; i++){
for (int j=0; j<2; j++){
std::cout << "i at: " << &i << std::endl;
std::cout << "j at: " << &j << std::endl << std::endl;
}
}
return 0;
}
~ $ g++ test.cpp
~ $ ./a.out
i at: 0xbffff97c
j at: 0xbffff978

i at: 0xbffff97c
j at: 0xbffff978

i at: 0xbffff97c
j at: 0xbffff978

i at: 0xbffff97c
j at: 0xbffff978

[bbi5291]

If the compiler did no optimization whatsoever, then in each iteration of the outer loop, a zero would be pushed onto the stack (with the variable "p" referring to its address) and at the end of each iteration it would be popped off. So you wouldn't be using 400 bytes; you'd be using 4 bytes over and over again. Also, stack allocation and deallocation are very fast; I would be willing to bet that they can be accomplished by one instruction each on most architectures. But leave automatic memory management to the compiler; it knows how to make your code efficient.

[mirhagk]

okay thanks, I was just wondering. It doesn't matter with ints, but for instance inside a class's method I declare a 4x4 matrix, now it'd be better to make a static class-wide global matrix called temp or something that I use for each method that needs one. Or does it automatically do something like that?

[OneOffDriveByPoster]

mirhagk @ Sun Jan 02, 2011 6:52 pm wrote:

okay thanks, I was just wondering. It doesn't matter with ints, but for instance inside a class's method I declare a 4x4 matrix, now it'd be better to make a static class-wide global matrix called temp or something that I use for each method that needs one. Or does it automatically do something like that?

If you do not really need to share this matrix, then use an automatic variable inside the function. It makes it easier for someone (and the compiler) to figure out what your code does.

[mirhagk]

Yes of course, but that means that it would be declaring a matrix for each object each frame. That doesn't seem right.

[chrisbrown]

mirhagk @ Sat Jan 01, 2011 10:51 pm wrote:

Everyone always says use local variables

They say this for a reason.

Variables allocated within a function call are located on the stack, not the heap, and making that space is a simple as calculating the required size. This triviality is one of the reasons local variables are preferred.

This does not always hold for complex data types (e.g. objects), but in general, use a local variable whenever you don't care about it after the function returns.

[OneOffDriveByPoster]

mirhagk @ Sun Jan 02, 2011 9:30 pm wrote:

Yes of course, but that means that it would be declaring a matrix for each object each frame. That doesn't seem right.

Why? If you are not in the middle of a call to a function that needs such a temp, no memory is being used for such a temp. Only stack frames for functions needing such a temp would have one.