Benchmarking the effect of caching 'transform'

[simonwittber]

After doing some extensive work extending NGUI for a client, I decided to benchmark the practice of caching the GameObject.transform field, and accessing it via cachedTransform.

You may find my results interesting, they showed very little speedup, however using a local variable instead yielded twice the performance. Package attached with benchmarking code.

[Nicki]

Interesting. If the cached has to grab the proper transform to cache it this would make sense, but if it has cached it, then subsequent accesses should be as fast as a local variable.

[ArenMook]

That's not exactly a surprise. You're seeing the overhead of accessing a property versus using a local variable.

This still stands:
1. It's faster to access the property of a cached variable than it is to access .transform.
2. The less you access properties and the more you use local variables, the better.

It's even faster if you do Transform t = cachedTransform;, then use 't'.

1. void TestProper ()
2. {
3.         System.Diagnostics.Stopwatch stopwatch = new System.Diagnostics.Stopwatch();
4.         stopwatch.Start();
5.         Transform t = cachedTransform;
6.         for (int i = 0; i < 100000000; i++)
7.         {
8.                 if (t.position.x == -1f) return;
9.         }
10.         stopwatch.Stop();
11.         Debug.Log(string.Format("Proper: Time elapsed: {0}", stopwatch.Elapsed));
12. }

Uncached: 13.794869 sec
Cached: 11.300586 sec
Local: 6.350196 sec
Proper: 6.343840 sec

[ArenMook]

I wonder how long it will take someone to notice that accessing a script's "gameObject" property is also expensive...

[Nicki]

I thought .gameObject was automatically locally cached. 

I must go.. and make some modifications..

[ArenMook]

It certainly isn't cached. I was doing some deep profiling the other day and noticed that accessing my script's gameObject property 167 times was costing something like 0.2 of a millisecond... which, with 1 ms per frame was quite expensive to say the least.