Ive learned from c++ that i should use
private variable;
function ChangeVariable( value )
{
variable+=value;
}
function GetValue()
{
return variable;
}
But here i can just made the variable public and directly manipulate it from another scritp, and since in both cases i need to “getcomponent” to access variables and functions it seems to be easier to just use the public variable, the question is, should i?
First of, when you are aiming for speed and only considering the performance aspect then yes, public fields are faster.
But, and this is a big but, you dont want to have public fields. In general terms you would use properties, means getters/setters to get full control over accses on that certain field.
A property is btw nothing more than a method, but way more convenient. Methods (so aswell properties) do always have a slower perfomance than direct accses since they need to be called. However, for small properties and methods there is a great chance that it gets inlined by the JIT.
As of getcomponent, you should always cache the components you are fetching so you dont have to constantly call it.
On the other aspect, it doesnt matter if you accses the field directly or via a method, you’ll always have to get the component first. -
public fields are not faster, although im yet to prove if this is only while playing in the editor, which I expect.
tbh, its so trivial it doesnt matter. There are bigger performance fish to worry about.
Got it, thanks.
Infact they are… Direct accses is always faster than going throught another level of indirection. Of course this depends on the JIT, if it inlines the certain method or not.
In fact they are not. Feel free to benchmark it; if all you’re doing is getting/setting and not performing additional operations, then properties are inlined and exactly as fast as public fields. (It’s not just in the editor; it wouldn’t really make any sense for code to be compiled differently in the editor vs. builds.)
–Eric
The time wasted in trying to optimize these nanoseconds usually means less time available to optimize milliseconds.
1 millisecond == 1 million nanoseconds. We’re talking about being literally millions of times more efficient with development time.
You can almost always get better performance per development hour by looking at graphics related things (or physics, or bad recursive loops, or anything else…)
Feel free to read my post again.
Yes, I saw that and in fact that is what I was replying to…
–Eric
Than I dont quiet get what you wanted to point out since you’ve just repeated my words in your words. 
By in the editor, I meant the overhead of updating the UI to reflect changes. Beyond that I wouldnt expect any difference.
Though, to bring up another point, in the editor the profiler gets attached to the code which might imply a certain overhead.
Only if the window is open I believe…
I only open that thing up when im on a optimisation mission… be interested to know if this was not the case, but pretty sure it is.
Im pretty sure of this. 
This is wrong; that’s all. But don’t take my word for it, see for yourself.
–Eric
I dont see where this should be incorrect. Infact im obviously correct with the sentence… To rephrase my words, direct access such as accessing public fields is always faster than calling a method/property. Do you really want to argue against this statement? o.0 Obviously direct access MUST be faster, since calling the method/property does involve 5 more IL opcodes. More work → slower.
However, that wasnt everything I’ve said. To continue my words, “As long as the JIT doesnt inline it”. Inlining implies the method/property code which is called being moved to the caller site. In terms of our public fields this would effectively make a property as fast as a public field.
So now tell me were I was wrong? In saying that direct access is faster? It is but I’ve aswell said that this is only true as long as it doesnt get inlined.
So yet again, I dont see what point you want to make since this has been all said by me before.
However, as of benchmarking inlining? The simple test would involve calling the method several million times in a loop. It will most likly get inlined in the benchmark, however, that does not say that in real code it will be inlined aswell. This does come from the fact of the JIT being more aggressivly inlining methods in loops, giving them a higher priority.