I was wondering what the effect, if any, is of having too many global variables defined. I used to finish up a script by defining any globals it created as undefined so that they could get cleaned out. But I’ve gotten lazy over time and now just leave them floating around even after the script that used them is no longer running.
I try not to use them possible, but sometimes I just can’t get around it. So I’m just curious if they could potentially be an issue after a while with more variables being added to the global pool as new scripts are run.
essentially, yes.
If you have a global variable “temp” that you use…
… and another script comes along and uses the global variable “temp” …
…and your script then gets the value of “temp” again expecting it to be the same as it was before… you’re in trouble.
If you honestly can’t get around global variables for whatever reason, prefix them… for example, if your script was called “wrangleSomething”, you might go with “jh_ws_temp”. That way, at least, it becomes increasingly unlikely that any other script would use the same variable name.
If you find a particular script uses several global variables, consider making them variables inside a struct instead. That way you only have to keep the struct instance assigned to a single global variable, and access the other ‘global’ variables from there.
Thanks. I’m aware of possible name collisions, so I make sure to use big, clunky variables names specific to a particular script. I’m more wondering about the effect on memory and performance.
When you say to store them in a struct so that you’re only using the one global, why exactly is that important? Why not just use 10 globals (for example)?
Well, unless your global variables contain heavy data (large bitmaps, huge arrays, etc.) I wouldn’t worry too much about that. Getting lazy about them is still bad, of course
If you want to go really hardcore, you can remove global variables in 3ds Max 2009 at least… but it comes with a big fat red warning in the help file.
Mostly for the sake of not having 10 globals, preventing collisions even further, etc. It’ll do nothing for keeping memory consumption down; in fact, it’ll use more. On the other hand, you can get very lazy about the variables within as setting the variable that holds the struct to undefined and doing a ‘gc light:true’ should clear all of the memory used by the variables within that struct up.
I just group together all my global variables into Script Specific structs.
Bob’s script has
struct BobVarsStruct (temp, temp2, temp3, information, data, data3)
then at the head of my script
BobVars = BobVarsStruct()
Then it’s all nice and organized. I also have all my script specific functions in there. Then the only variable I need to worry about is BobVars.
Sounds like the way to go. Thanks guys.
Further reason to use a big struct is it helps when you’re using global variables from other scripts.
I use a lot of fileins from other script’s function libraries so if I call a variable from ScriptA
It has ScriptA.DefaultBoxWidth for easy reading.
If you use a filein and start using functions and vars from other scripts you might not immediately recognize where the variable came from.