Speed vs. Memory
Author
If there is a variable that is needed in a function, would it be better to make it global or create it when the function is called? On one hand it would be better for memory to create it when the function is called, but would it bring down performance to do so if the function is called several times?
-Chris
Well, unless the variable is defined as static <type> <name>, any variable created during a function is only around as long as the function is being excecuted. As soon as the function ends, all the instance variables (ie all the variables created by the function) go away. If you define a function variable as static, it will be available every time the function is called, with the same value as it had the last time the function ran. So unless you need to keep the variable's value every time the function runs, just declare it in the function, and make sure you clean it up when the function ends, and you should be ok, as you'll only be using memory when the function runs, as opposed to having a variable thats global, taking up space for the entier program run.
if it's only used in that function there's absolutely no reason why it should be global. In fact having a local variable can be faster and use less memory, since the compiler can shove it into a cpu register and use zero memory.
But even if there were no performance benefits, it makes your code a lot cleaner. Avoid globals where possible.
But even if there were no performance benefits, it makes your code a lot cleaner. Avoid globals where possible.
Always prefer locals to globals. The less code that knows about the variable, the better.
Beginners need not involve themselves with matters of speed. Correctness and cleanliness above all else.
Beginners need not involve themselves with matters of speed. Correctness and cleanliness above all else.
I also wonder about this..
lets say you have a class and in that class you have several functions
that would all need a temp variable of the same type... would it be better to keep a private variable of that type in your class.. or reinstanciate that variable for each of your functions...
class wide
pro:
only constructed once
only deconstructed once
con:
stays around in memory until class is deconstructed
function wide:
Pro:
only in memory while being used
con:
has to be constructed and deconstructed each function call
the pros and cons increase the larger the data type is
im not sure wich is best but i tend to stick with class wide
lets say you have a class and in that class you have several functions
that would all need a temp variable of the same type... would it be better to keep a private variable of that type in your class.. or reinstanciate that variable for each of your functions...
class wide
pro:
only constructed once
only deconstructed once
con:
stays around in memory until class is deconstructed
function wide:
Pro:
only in memory while being used
con:
has to be constructed and deconstructed each function call
the pros and cons increase the larger the data type is
im not sure wich is best but i tend to stick with class wide
Quote:Original post by MTclip
I also wonder about this..
lets say you have a class and in that class you have several functions
that would all need a temp variable of the same type... would it be better to keep a private variable of that type in your class.. or reinstanciate that variable for each of your functions...
class wide
pro:
only constructed once
only deconstructed once
con:
stays around in memory until class is deconstructed
function wide:
Pro:
only in memory while being used
con:
has to be constructed and deconstructed each function call
the pros and cons increase the larger the data type is
im not sure wich is best but i tend to stick with class wide
Err, don't worry so much about very [VERY] minor optimizations. Go with the one that looks the best and makes it easy to tell what's going on (which most people will probably agree is the second one).
Well if it's your own data type, and you have expensive constructors and destructors for it, then that might make a little sense. But you'd probably be amazed at how little of your time it takes anyhow (processors are fast, if it's not in a double loop it doesn't really matter). But if it's just a built in data type then it will always be better to create it in the function. They have no constructor/destructor, so it will just be hardcoded in to use a certain stack offset as that variable - or not even that.
EDIT: There can actually be cases where it's nice to do it the class wide way, but for different reasons. Like an iterator for a container might be class wide so it's easier to change it's type and template parameters.
EDIT2: Oh, and don't worry about memory till you allocate arrays of 67108864 floats or similar. Like I did for one of my projects...
EDIT: There can actually be cases where it's nice to do it the class wide way, but for different reasons. Like an iterator for a container might be class wide so it's easier to change it's type and template parameters.
EDIT2: Oh, and don't worry about memory till you allocate arrays of 67108864 floats or similar. Like I did for one of my projects...
Quote:Original post by MTclip
class wide
pro:
only constructed once
only deconstructed once
con:
stays around in memory until class is deconstructed
function wide:
Pro:
only in memory while being used
con:
has to be constructed and deconstructed each function call
Generally, go for the "pretty" solution.
This is definitely a microoptimization that won't make any kind of noticeable difference, so go for what gives you the cleanest, most robust code.
Which usually means go for the most local version you can. As others have said, the less code that has access to the variable, the better. Means the compiler can optimize more.
If the function is going to overwrite the variable every time you call it anyway, then making it a class variable is a bad idea. (And if it doesn't overwrite it, then we're talking about a variable that needs to survive between function calls, and then a class variable suddenly sounds like a good idea)
Locals should stay local. If it made sense speed-wise for them to act like a global the compiler would treat them all as global itself (it dosn't, which tells you that it's a bad idea).
The fact of the matter is that local variables end up in registers (outragously fast, "zero" memory usage), or on the stack (fast, uses memory that is already allocated for the stack).
If you make it global, you risk having it page around slowly (whereas your stack is all in the same place) and you're always using that memory. And you prevent the compiler from doing most kinds of optimisations on it.
Anyway, as was said before, all good programmers code for readability (local and pretty code) first, and then speed only after they've programmed it properly. And then only after they've profiled it to find the slow spots, and then only when they know exactly what they're doing.
Not really.
You should be using a typedef in this case.
The fact of the matter is that local variables end up in registers (outragously fast, "zero" memory usage), or on the stack (fast, uses memory that is already allocated for the stack).
If you make it global, you risk having it page around slowly (whereas your stack is all in the same place) and you're always using that memory. And you prevent the compiler from doing most kinds of optimisations on it.
Anyway, as was said before, all good programmers code for readability (local and pretty code) first, and then speed only after they've programmed it properly. And then only after they've profiled it to find the slow spots, and then only when they know exactly what they're doing.
Quote:Original post by RAZORUNREAL
EDIT: There can actually be cases where it's nice to do it the class wide way, but for different reasons. Like an iterator for a container might be class wide so it's easier to change it's type and template parameters.
Not really.
You should be using a typedef in this case.
Use local vars as much as possible. Globals have side effect that programmer thinks they're being used elsewhere when they might not be. Just being used for speed in your case. The more mental clutter you reduce the better. Also, profile code when in doubt. Think of frequency of code invokation and application response time requirements.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
