Does reading/changing Static variables constantly affect Performance or get Garbage Collected?

Questions & Answers
1

From the last question that i asked, @Bunny83 said:

GUI.enabled is just a state stored in an internal field. There is no overhead involved setting that state.

So GUI.enabled is a static bool, and i think static variables only have 1 reference, so when you access/change it somewhere, it will be accessed/changed for the others.
So i’m mostly talking about Performance Improvement, does the last line improve performance at all?

bool enabled = false;
//Set it to (enabled) bool
GUI.enabled = enabled;
//Check if it isn't equal to (enabled) bool, so it isn't necessary to change it to the same value if
//it is already (false), which it is equal to (enabled) bool, so the condition won't pass
if(GUI.enabled != enabled)GUI.enabled = enabled;

Also Event.current is a static variable as well, so if i do:

Event current = Event.current;
if(current.button == 0)
    print("Left Mouse Button is pressed);

Does the (current) variable that i just created affect performance? or get garbage collected?

Event.current.button is a public non static variable, so it has a reference to itself, so caching it into a variable is a good practice to increase performance?

Also GetComponent()isn’t static as well, people suggest caching it, so it looks like Event.current.button should be cached when it gets used a lot!

And List.Count isn’t static too, so i ran 2 different tests showing the difference between a cached List.Count and a non cached List.Count and it turned out that the cached List.Count is way too much faster than a non cached List.Count.

So can somebody explain it to me or confirm if it is true?

Thanks.

[EDIT] Just for your info, i have experience of about 3 years in Unity3D, so you don’t need to explain the very basic stuff, i just talk about the Performance, so yeah…

2

First of all you do put way too much efford into micro optimisations here. As i said in the enabled case it’s complete nonsense. Yes GUI.enabled is a property and therefore actually a pair of two methods (a get and a set method). Of course calling those methods which actually call a function in the C++ engine core has a slight overhead. However just reading the property has the same overhead compared to writing to it. So if you check the current state before you set it you actually make the performance worse.

Event.current is a static property just like GUI.enabled. However unlike the enabled property which is a boolean value, the current property is of type “Event” which is a class and therefore a reference type. Storing the same reference in a local variable and using the local variable has only a minimal improvement on the access time. The main reason why you usually cache the current Event at the top is because it makes the code more readable as the variables gets shorter.

I highly doubt that you will access current.button that many times that its even in the range that the difference can be measured. Local variables do not get garbage collected. Local variables are allocated on the stack when you enter the method.

List.Count is also a property. Therefore reading the value has a slight overhead since it’s actually a method call. However testing such things in the editor can lead to wrong results since in a built game the JIT compiler can optimise getter methods by inlining them. I also run test on the performance of List.Count and compared to a local variable the rough difference is that a local variable is about two times faster. This is not even worth mentioning. Pretty much anything you actually do with your list elements will be several times slower than the for loop.

Actually caching the Length of an array can actually have a negative effect on certain optimisations. Reading the length of a native array is actually a seperate IL opcode (ldlen).

You seem to be heavily affected by permature optimisation. For example as i said caching the count of a list decreases the access time of the count variable by a factor of 2. However if your loop actually draws each item, the drawing will probably be 95% - 99% of the time spent per iteration. So changing to a cached count most likely can’t be even measured. Especially if you just have a few elements.