Co-worker pushes for private transform for each moving object.

I need to settle a debate.

A coworker of mine is insisting that all moveable objects, such as the player and enemies should all have their own personal transform. He claims it is more efficient and will boost performance.

Like so:

Code (CSharp):

1. public class player : MonoBehaviour {
2.  
3. public Transform myTransform;
4.  
5.      void Start () {
6.           myTransform = transform;
7.      }
8.  
9. }

Thus to set a position to another objects position would be done as so...

Code (CSharp):

1. myTransform.position = Enemy.myTransform.position;

I honestly think this is makes little difference, and I insist that we just use the standard "transform" keyword for cleaner code. This is what is generally used in the tutorials anyway.

How should we do this. Is what he is saying correct?

(BTW, we are using the latest version of Unity 4 Pro.)

 

Run both versions in the profiler and see what you get.

Also, look at the property in an IL decompiler (e.g. ILSpy) and see what it's doing behind the scenes when accessing the transform property. I don't recall for sure if Unity 4 caches the transform property or always does a GetComponent call, but I believe I read somewhere that it's cached in Unity 5. You can find out by examining the code and/or testing performance in the profiler.

 

It's cached in Unity 4, too:

Code (csharp):

1. public Transform transform
2. {
3.      get
4.     {
5.         return this.InternalGetTransform();
6.      }
7. }
8.  
9. [WrapperlessIcall]
10. [MethodImpl(MethodImplOptions.InternalCall)]
11. internal extern Transform InternalGetTransform();

In Unity 3 and earlier, though, you had to cache the transform yourself.

You can use the transform property directly. However, don't get too comfortable using other built-in properties such as rigidbody. They're gone in Unity 5. They only kept transform.

 

@TonyLi , how are you able to look at the API source code? Is that a feature of Pro edition?

 

Ive always been an advocate of caching anything you intend to access via Update/FixedUpdate. Whether it makes much difference these days, Im not sure. Its an old practice that was always important. Im not convinced the Getter posted above is more/less efficient. End of the day, its still a getter calling a function, which is overhead. It might be a very small amount of overhead, but its still there.

 

This is what I would tend to do in performance critical code as well, but I'd profile it first.

@MikeTeavee You can use the ILSpy tool I linked above to look at C# code, or there are other tools to do that as well.

 

@Dave-Carlile Oops! I didn't understand your post above. Thanks!

 

Yeah I've spent many hours staring at the profiler. I do love to optimise (or so you would think!). The project Ive spent the longest on started back in version 3 though, when it was important. Now its just ingrained in me I think.

 

I actually copy-pasted someone else's ILSpy output in my reply since I wasn't near Unity at the time.

I agree that profiling is the best way to really know. But there's value in simplicity, too. If the profiler doesn't indicate much difference (and it shouldn't in Unity 4+), I'd use the transform property just to have less code. Every extra line of code is extra potential for a bug, and it's also more code that a new reader has to keep in mind when they're reading your code.