koobas.hobune.stream
Are .gameObject and .transform both using GetComponent() in the background?
I know .transform usage should be cached for optimization. I can get around that by directly storing the Transform of the object so I can just say:
var myObject : Transform;
myObject.position = Vector3.zero;
However, if I also need to access the GameObject (in this case, to set it as active/inactive), does using myObject.gameObject also use a hidden GetComponent lookup as .transform does, or is .gameObject a special case?
A GameObject is not a component (it's a container for components), so no, there is no possibility of using GetComponent in that case. The .transform shortcut is not actually using GetComponent either...there are three levels, in order of slowest to fastest: 1) GetComponent(Transform), 2) .transform, and 3) cached Transform such as your code example. Although "slowest" is relative; in reality there's not a huge difference, and while caching it certainly doesn't hurt, it may not result in any noticeable gains, unless you're really accessing that component a lot.
Ah, so I shouldn't be as worried about using accessor shortcuts as the Unity optimization leads me to believe? I'll have to reconsider the way I'm coding right now. So much conflicting info. Thanks!
So to put some scale on it:
In this first comparison a cached transform takes 0ms on my computer.
transform = 0.000622ms
GetComponent(typeof(Transform)) = 0.001009ms
GetComponent< Transform>() = 0.00157ms
So clearly if you were looking a 1000 in a few loops every frame it would become worth caching (on my computer - i$$anonymous$$ac 3.4Ghz), it might be significantly more on worthwhile on a mobile device.
It appears:
GetComponent(Type) is 1.6x slower than transform
GetComponent< Transform>() is 2.5x slower than transform
In a second test, to compare cached transforms against transform I access the name property and that yields a cost of:
0.000817ms cost per usage of transform versus a cached transform. In this case making the non-cached code 20% slower than the cached version.
I should also point out that using .position is 19% slower than .localPosition when the object has no parents, rising to 28% with one parent and increasing for every level of parent above.
Some of the conflicting info exists because this stuff (that is, GetComponent) used to be slower than it is now. But at some point they optimized it. Fancy that. ;)
And yes, whydoidoit re$$anonymous$$ds me that it's actually 4 levels, since the generic GetComponent is a bit slower: 1) GetComponent.(), 2) GetComponent(Transform) (and the long-winded C# equivalent), 3) .transform, 4) cached version.
Does someone knows why transform is slower than cached transform ?
