koobas.hobune.stream
[ANSWERED] c# performance impact - Global variables vs Local variables
Hello everyone,
My friend (1st year cs + games undergrad student) and I (recently self taught amateur spaghetti creator) were discussing Global variables and the impact of scope on performance in c#.
After reading a Reddit post in which a certain automotive manufacturer's source code was slated for having thousands of Global variables, I began to worry about my own classes and my potential overuse of global variables. As a self taught amateur, I have never had anyone around to tell me "You idiot, you have initialised 15 global variables in a 50 line class" etc..
Basically, I would like to know what is more efficient:
Note: "someArg" most likely will be a variable that changes frequently, up to once per Update cycle
http://pastebin.com/LAxSqn7k (Initializing a global variable outside of the Update function) or
http://pastebin.com/XwdzhexH (Initializing a local variable every update)
or
http://pastebin.com/svMYANkV (I don't even know what this is called... )
As someone who has yet to study computer science, I have no idea how c# actually handles this... Does it create and destroy local variables every cycle? Or does it intelligently store local variables in memory until they are no longer needed? What if it isn't needed for a while, but then it is needed again later? I assume that the c# garbage collection works some magic here. I think that I should figure this out (with your help) before it becomes a stubborn problem...
Anyway...
TLDR: See the 3 pastebin links above - which one is the most efficient... And are Global variables bad enough to warrant changing my current style?
Your first example is not a global variable. It is a variable within a class. If that class has not been instantiated as an object, the example variable doesn't exist in memory. Furthermore, even if you have instantiated an object of that class, that variable is still not accessible globally . It is only accessible if you have a reference to the object, and it is also unique for that object. In other words, if I create 5 objects, they each have their own example variable with their own value.
A global variable means that you have a variable that anybody can access and change from anywhere in code and is always in memory.
And in fact, a global variable doesn't affect performance so much as it completely messes up your code. It's more of a bad design practice than a performance consideration.
Now, your code files are not global variable related, but they are performance related. In your first file, you store the example variable once and reuse it on update. This is pretty good because GameObject.Find is a pretty costly operation, so the fewer times you do it, the better (and in Unity, you can completely avoid it by linking game objects or tagging them)
In your second file, the your example variable is stored in the stack (as opposed to the heap), because it is defined within the confines of a method which will get destroyed once the method ends executing. So the variable's memory is not a concern. Performance the second and third files are nearly identical.
The real performance issue in your second and third is calling GameObject.Find every frame. The variable declaration is negligible.
Wow this is the perfect answer, thanks very much for that! It makes a lot more sense now.
This is a really good answer, but i wondered you said that objects instantiated in a method is stored in the stack and destroyed at the end but is this true with reference type classes like a Transform ? because Vectors and Quaternions are structs so they are ok because they are primitives but reference type objects are always stored in the heap right ?
You are correct, reference types are always stored on the heap. I was simplifying to make a point. But if they are declared in a method, just like value type, they are destroyed at the end of that method because they are all declared in local scope. The difference is that reference type are not immediately destroyed, they are just waiting to be destroyed by the garbage collector at some time in the future. Normally that wouldn't have any difference in practice, but in video games it is a huge deal when you are creating objects every update. You'll fill your heap before the garabage collector is triggered and when it finally does trigger, it might freeze your game because of the amount of memory it needs to clean up. In those cases you either find an alternative way, or use Object Pools.
