Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Cache transform: really needed?

Discussion in 'Scripting' started by KazYamof, Sep 23, 2015.

Thread Status:
Not open for further replies.
  1. KazYamof

    KazYamof

    Joined:
    Jun 26, 2015
    Posts:
    59
    Hi there,

    I usually do the cache components that I need to use on my scripts by doing GetComponent<T> on Awake() or Start(). But recently, readin the book C# Game Programming Cookbook for Unity 3D (2014), the author do the cahe even to transform.

    Question: is it really necessary even in Unity 5, since the 'transform' is accessible directly on MonoBehavior.? We don't have this kind of optimization encapsulated yet? And there is someway to measure the results of this optimization?

    Thanks!
     
    psychicparrot and Hunter_Bobeck like this.
  2. KelsoMRK

    KelsoMRK

    Joined:
    Jul 18, 2010
    Posts:
    5,539
    No - transform get was optimized in 5 so you no longer need to cache it yourself.
     
    Bvenjamin and Hunter_Bobeck like this.
  3. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    7,462
    I've found myself using Transform where I used to use GameObject in a lot of cases now. Maybe he is caching it just for shorthand convenience.
     
  4. KazYamof

    KazYamof

    Joined:
    Jun 26, 2015
    Posts:
    59
    Thanks @KelsoMRK. Do you know where we can find this information? Is an Unity 5 release note?
     
  5. KelsoMRK

    KelsoMRK

    Joined:
    Jul 18, 2010
    Posts:
    5,539
    Release Notes for 5 state that GetComponent was improved across the board. I found it specifically somewhere but not sure where at this point.
     
  6. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
  7. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Caching components yourself is still faster than GetComponent. (This includes Transform.) In most cases it won't really make any difference and isn't worth bothering with, but nevertheless it's something to keep in mind. The line in the blog about Transform being cached is not true. You have to do it yourself if you want the speed benefits.

    --Eric
     
  8. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    Are you sure? Our understanding was this was the exception, that it was a direct reference, since all gameObjects have transforms. Is it noted somewhere that this isn't the case?
     
    Mehrdad995 and Hunter_Bobeck like this.
  9. KazYamof

    KazYamof

    Joined:
    Jun 26, 2015
    Posts:
    59
    Hunter_Bobeck and Harinezumi like this.
  10. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    I'm quite sure. It's pretty trivial to run benchmarks or use the profiler to confirm this.

    --Eric
     
  11. HiddenMonk

    HiddenMonk

    Joined:
    Dec 19, 2014
    Posts:
    987
    I posted in another thread a speed test of transform, but ill put it here as well.

    Code (CSharp):
    1. using UnityEngine;
    2. using System.Diagnostics;
    3.  
    4. public class TestTransformSpeed : MonoBehaviour
    5. {
    6.     Transform myTransform;
    7.     Transform myTransformGetter {get {return myTransform;}}
    8.     int iterations = 1000000;
    9.  
    10.     void Start()
    11.     {
    12.         myTransform = GetComponent<Transform>();
    13.  
    14.         TestTransform(); //result = 00:00:00.0923923 (~92 Milliseconds)
    15.         TestMyTransform(); //result = 00:00:00.0694768 (~69 Milliseconds)
    16.         TestMyTransformGetter(); //result = 00:00:00.0739161 (~74 Milliseconds)
    17.     }
    18.  
    19.     void TestTransform()
    20.     {
    21.         Stopwatch stopWatch = new Stopwatch();
    22.         stopWatch.Start();
    23.  
    24.         for(int i = 0; i < iterations; i++)
    25.             transform.position = Vector3.zero; //transform uses a Getter to retrieve the transform. Not sure whats in the getter.
    26.  
    27.         stopWatch.Stop();
    28.         UnityEngine.Debug.Log(stopWatch.Elapsed);
    29.     }
    30.  
    31.     void TestMyTransform()
    32.     {
    33.         Stopwatch stopWatch = new Stopwatch();
    34.         stopWatch.Start();
    35.  
    36.         for(int i = 0; i < iterations; i++)
    37.             myTransform.position = Vector3.zero;
    38.  
    39.         stopWatch.Stop();
    40.         UnityEngine.Debug.Log(stopWatch.Elapsed);
    41.     }
    42.  
    43.     void TestMyTransformGetter()
    44.     {
    45.         Stopwatch stopWatch = new Stopwatch();
    46.         stopWatch.Start();
    47.  
    48.         for(int i = 0; i < iterations; i++)
    49.             myTransformGetter.position = Vector3.zero;
    50.  
    51.         stopWatch.Stop();
    52.         UnityEngine.Debug.Log(stopWatch.Elapsed);
    53.     }
    54. }

    This was all done in Unity 5.0.2f1

    The speed difference is small, so I wouldnt worry about it.
     
    valentin56610 likes this.
  12. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    I just gave it a try, and you are partially correct. Or rather, you are completely correct that it is faster to locally cache, but .transform is much faster than GetComponent (for transform). So presumably as the article says, caching is happening, there just is a small amount of overhead. Good to know. Thanks!

    Code (CSharp):
    1.             GetComponent<Transform>()
    2.             ----------------------------------
    3.             00:00:00.1267660
    4.             00:00:00.1392190
    5.             00:00:00.1192030
    6.             00:00:00.1212520
    7.             00:00:00.1171210
    8.             00:00:00.1203210
    9.             00:00:00.1212310
    10.             00:00:00.1162110
    11.             00:00:00.1318870
    12.             00:00:00.1318870
    13.  
    14.             .transform
    15.             ----------------------------------
    16.             00:00:00.0746700
    17.             00:00:00.0889320
    18.             00:00:00.0816240
    19.             00:00:00.0850060
    20.             00:00:00.0813800
    21.             00:00:00.0728400
    22.             00:00:00.0861790
    23.             00:00:00.0867240
    24.             00:00:00.0838280
    25.             00:00:00.0851020
    26.  
    27.             myTransform (cached)
    28.             ----------------------------------
    29.             00:00:00.0731950
    30.             00:00:00.0631190
    31.             00:00:00.0667700
    32.             00:00:00.0701300
    33.             00:00:00.0640030
    34.             00:00:00.0652790
    35.             00:00:00.0628240
    36.             00:00:00.0586720
    37.             00:00:00.0650240
    38.             00:00:00.0634400
    39.  
     
  13. KazYamof

    KazYamof

    Joined:
    Jun 26, 2015
    Posts:
    59
    Nice test. But you only set the position to 0,0,0. What about some randoms operations in Scale and Rotation too?
     
  14. HiddenMonk

    HiddenMonk

    Joined:
    Dec 19, 2014
    Posts:
    987
    I dont see what that would prove. The test is only to see which call to transform is faster. What you do afterwards is irrelavent as long as its the same for each test.
     
  15. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    For the purposes of the test these would simply cloud the issue with more overhead. Setting the position to 0,0,0 is probably the most consistent operation that incurs the smallest penalty.
     
  16. KazYamof

    KazYamof

    Joined:
    Jun 26, 2015
    Posts:
    59
    That's true. I thought the compiler could be doing some pre-optimization because it can 'see' the fixed operation there, and just replicate a previous result to the next one on the loop, generating a small variation between them.
     
  17. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    I wish the compiler was that smart.
     
    Hunter_Bobeck and Decal_T17 like this.
  18. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    Heh, just did a quick couple of tests using Random.rotation for kicks and most of the results were so high that the variance between the runs was larger than the difference in between the different versions of how the transform was being reference was being called.
     
  19. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Got an ANOVA for us? :)
     
    radiantboy likes this.
  20. shawnblais

    shawnblais

    Joined:
    Oct 11, 2012
    Posts:
    324
    Just ran some tests on this in Unity 2017.1, with the new 4.6 .NET compiler, if anyone is interested.

    Doing 100,000 calls to GetComponent<Transform> and GetComponent<Rigidbody> and GetComponent<Foo>:
    Transform = 4ms (.00004ms / call)
    Rigidbody = 4ms
    Foo = 14ms (.00014ms / call)

    So it appears as those native components are cached somehow, or at least about 3x faster to lookup than custom scripts, and while the custom GetComponent is still fairly fast, I think the performance hit still justifies caching, especially in your update loop.

    Using a design pattern like this, you can get your custom scripts down to the same performance as native, without much extra code:
    Code (CSharp):
    1. public T GetCachedComponent<T>(ref T c) where T : Component {
    2.     if (!c) { c = GetComponent<T>(); }
    3.     return c;
    4. }
    5.  
    6. Foo foo;
    7. public Foo Foo { get { return GetCachedComponent(ref foo); } }
    8.  
    9. Bar bar;
    10. public Bar Bar { get { return GetCachedComponent(ref bar); } }
    11.  
    12. //etc
    13.  
    It has one big flaw though, if your component does not exist, performance spikes by 10x.

    Doing 100,000 calls to GetComponent<MyMissingType>(), takes 450+ms(!), so you still need to be very careful you're not calling this each frame to check if the component exists, it could burn you.

    Overall, due to the very high costs of checking for a missing component, and the extra cost for custom components, I think best practice remains to manually inject your component dependancies in the editor, or wire them up once in your Start() method.
     
    Last edited: Aug 10, 2017
    Stormer2020, neonblitzer and Kiwasi like this.
  21. KelsoMRK

    KelsoMRK

    Joined:
    Jul 18, 2010
    Posts:
    5,539
    "the fastest operation is the one you don't perform" etc etc :)
     
  22. monotoan

    monotoan

    Joined:
    Feb 13, 2015
    Posts:
    11
    Just ran @HiddenMonk 's test and got results very similar to @zombiegorilla ... A cached transform variable seems to perform 40% faster than a direct call to gameObject.transform.

    BUT... given how little time either approach takes in the first place, it's hard for me to think of a case where this optimization would be what makes or breaks your performance.

    For example, while it's true that if you were modifying 10,000 transforms in one frame, switching to cached transform references would save you 0.3 milliseconds (total) each frame, if you're modifying that many transforms at once you're almost certain to be having other performance problems and/or have other options for optimization that would save you a lot more time per frame (like moving all those transform modifications into a shader).

    Seems like transform caching would only be worth it if you're working with somewhere in the range of 1000 transforms -- enough that saving a tiny bit of time each frame might be worthwhile, but figuring out an entirely different optimized method for doing whatever you're doing might not be?
     
    Kiwasi likes this.
  23. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    Every little bit helps, so thanks for all the effort put into this.

    I routinely develop code with a lot of stuff like:
    Code (csharp):
    1. GameObject.FindGameObjectWithTag("CoolTag").GetComponent<SomeScript>().SomeGameObject.GetComponent<ScriptIActuallyWant>().SomeMethod()
    and then later when that script has settled down I do an optimization pass on it to set up all the caching I need. I generally don't see any performance increase from just playing the game (I only am checking how performance improves in the profiler if I'm trying to correct a real problem), but it is nice to have some quantifiable data here that these kind of optimizations are making a difference and by how much.
     
  24. KelsoMRK

    KelsoMRK

    Joined:
    Jul 18, 2010
    Posts:
    5,539
    Even more so when the new entity system rolls out at which point if you're into the numbers required to see a performance gain you'll get more bang for your buck by not spawning GameObjects at all :)
     
  25. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    1,992
    Way back I was taught caching is a trade-off, and you have to consider that for tests. Using the cached variable is a speed-up, but having to carry it around is a slow-down. Running a million times only tests the speed-up part, but not the negative effect.

    In a real, large program, your data is loaded into fast L1 memory, crowding out older stuff; then in turn is kicked out; reloaded later; over and over. Having more data - that extra cached variable - makes that a tiny bit more frequent. It's the same mechanics as when a 2 gig memory starts to choke on a 1.75 gig program (looking up "thrashing computer" should get some explanations.) It's a tiny amount, but can swing things if you're caching based on "every tiny bit helps."

    ---

    For dot-transform vs. GetComponent speed: GetComponent has to set up a loop. I assume dot-transform is simply "components.First.value," since the Transform is known to be the first component.
     
    Appleguysnake and neonblitzer like this.
  26. KelsoMRK

    KelsoMRK

    Joined:
    Jul 18, 2010
    Posts:
    5,539
    I've never seen anything to suggest this. It literally used to always do GetComponent<Transform> which is how the whole caching thing came about in the first place.
     
    Kiwasi likes this.
  27. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    I would be absolutely amazed if components were stored in an ordered collection internally. It would be easy to test though, simply set up a bench mark to consider the difference between GetComponent on the first component vs the thirtieth.
     
  28. KelsoMRK

    KelsoMRK

    Joined:
    Jul 18, 2010
    Posts:
    5,539
    The Rider decompilation doesn't provide much insight. Seems like a dump straight into engine code (which might explain the nominal increase in performance when caching).

    Code (csharp):
    1.  
    2. /// <summary>
    3. ///   <para>The Transform attached to this GameObject.</para>
    4. /// </summary>
    5. public extern Transform transform { [GeneratedByOldBindingsGenerator, MethodImpl(MethodImplOptions.InternalCall)] get; }
    6.  
    In either case, relying on component ordering always seems incredibly dangerous to me.
     
  29. HiddenMonk

    HiddenMonk

    Joined:
    Dec 19, 2014
    Posts:
    987
    I did a test like that a while back in unity 5.0.2f1 and what I found was calling GetComponent for a script that was 2nd in the inspector (under transform) in a loop many times took 141ms, and calling GetComponent for a script that was 30th in the inspector took 497ms.
    Also, Image effects, based on what I read, is dependent on what order they are in the inspector, so I assume unity is keeping an ordered collection.
     
  30. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Huh. I guess its time for me to be absolutely amazed then. Thanks for following up.
     
    HiddenMonk likes this.
  31. KelsoMRK

    KelsoMRK

    Joined:
    Jul 18, 2010
    Posts:
    5,539
    The interesting implication to all of this is that it would appear you should order your components based on how often you access them via GetComponent
     
  32. PanicEnsues

    PanicEnsues

    Joined:
    Jul 17, 2014
    Posts:
    187
    Going one step deeper on this, I was surprised to find that accessing the individual properties of transform was quite a bit slower than caching them.
    E.g., 100k iterations of
    Vector3 pos = transform.position; // 00:00:00.1923777
    vs.
    Vector3 pos = myPosition; // 00:00:00.0423077

    Again, probably not worth caching unless you're reading transform.position thousands of times per frame.
     
    Russian_Bearman likes this.
  33. KelsoMRK

    KelsoMRK

    Joined:
    Jul 18, 2010
    Posts:
    5,539
    Is this the case even for properties that are backed by reference types?
     
  34. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    7,462
    Code
    Code (csharp):
    1.  
    2. using System;
    3. using System.Diagnostics;
    4. using UnityEngine;
    5.  
    6. public class test : MonoBehaviour
    7. {
    8.     private Vector3 _positionBacking;
    9.  
    10.     public Vector3 PositionBacking
    11.     {
    12.         get { return _positionBacking; }
    13.         set { _positionBacking = value; }
    14.     }
    15.  
    16.     public Vector3 PositionNoBacking;
    17.  
    18.     private int loops = 10000000;
    19.  
    20.     void Start()
    21.     {
    22.         Stopwatch stopWatch1 = new Stopwatch();
    23.         stopWatch1.Start();
    24.         for (int i = 0; i < loops; i++)
    25.         {
    26.             PositionBacking = Vector3.one;
    27.         }
    28.         stopWatch1.Stop();
    29.         TimeSpan ts1 = stopWatch1.Elapsed;
    30.  
    31.         string elapsedTime1 = string.Format("Backing: {0:00}:{1:00}:{2:00}.{3:00}",
    32.             ts1.Hours, ts1.Minutes, ts1.Seconds,
    33.             ts1.Milliseconds / 10);
    34.         UnityEngine.Debug.Log("RunTime " + elapsedTime1);
    35.  
    36.         Stopwatch stopWatch2 = new Stopwatch();
    37.         stopWatch2.Start();
    38.         for (int i = 0; i < loops; i++) PositionNoBacking = Vector3.one;
    39.         stopWatch2.Stop();
    40.         TimeSpan ts2 = stopWatch2.Elapsed;
    41.  
    42.         string elapsedTime2 = string.Format("NoBacking {0:00}:{1:00}:{2:00}.{3:00}",
    43.             ts2.Hours, ts2.Minutes, ts2.Seconds,
    44.             ts2.Milliseconds / 10);
    45.  
    46.         UnityEngine.Debug.Log("RunTime " + elapsedTime2);
    47.     }
    48. }

    Results
    Code (csharp):
    1. RunTime Backing: 00:00:00.38
    2. RunTime NoBacking 00:00:00.22
     
    valentin56610 likes this.
  35. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    1,992
    I think the usual comparison is with the same types: myCachedTransform.position vs. transform.position. Otherwise of course the second is faster -- it's 1 lookup shorter. A.B is one more step then just myCopyOfB.
     
    Hunter_Bobeck likes this.
  36. Suddoha

    Suddoha

    Joined:
    Nov 9, 2013
    Posts:
    2,824
    Erm, perhaps I'm mistaken, but wasn't he referring to properties of reference types?
     
    Hunter_Bobeck and KelsoMRK like this.
  37. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    7,462
    I probably misunderstood, went into my brain as 'i wonder if backing fields slow things down'.

    Might need some more coffee...
     
  38. Suddoha

    Suddoha

    Joined:
    Nov 9, 2013
    Posts:
    2,824
    Don't worry :D Btw, editor or build?

    It's actually not extremly surprising and the comparison is not fair to be honest.

    .transfrom is a property, so there's a small overhead even when it's cached
    .position is another property AND this time it also needs to return a copy of the actual position

    Anyway, same question: editor or build? In the editor, there is potentially some logic for debugging and profiling involved (dependent of the implementation - intrusive or not), which might be stripped in the final build, which again might lead to various optimizations...
     
  39. KelsoMRK

    KelsoMRK

    Joined:
    Jul 18, 2010
    Posts:
    5,539
    Good point but generally speaking if you're comparing relative performance between 2 or more methods the build target becomes less relevant as the increase in performance once you're out of the editor is pretty uniform across the board. It really just becomes a question of is this worth worrying about :)
     
  40. kgindemitsoulside

    kgindemitsoulside

    Joined:
    Nov 5, 2018
    Posts:
    3
    I just had a look at UnityCsReference\Runtime\Export\Component.bindings.cs file.
    The transform property implementation looks like this:
    Code (CSharp):
    1. public extern Transform transform
    2. {
    3.     [FreeFunction("GetTransform", HasExplicitThis = true, ThrowsException = true)]
    4.     get;
    5. }
    It seems that there is no caching of transform property.
     
  41. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    It is cached on the native side (At least Unity states so).
    If you cache it on managed side, you'll avoid uneccessary transform fetch call to / from native side.
    So it's still worth doing (if there's extra ram you can spend) if you're operating transform quite often.
     
    Rodolfo-Rubens and Kiwasi like this.
  42. chubshobe

    chubshobe

    Joined:
    Jun 20, 2015
    Posts:
    52
    Just had a go at this in the new 2019.3.5f1 release.

    upload_2020-3-16_14-10-34.png

    Uhh yeah. The first operation of every loop had the most noticable difference, it's also insanely high for whatever reason.

    Code:
    Code (CSharp):
    1. public class Test : MonoBehaviour
    2. {
    3.     private Transform myTransform;
    4.     [SerializeField] private uint calls;
    5.  
    6.     private void Start() {
    7.         myTransform = transform;
    8.         print("No caching:");
    9.         for (uint i = 0; i < calls; i++) TestNoCache();
    10.         print("Caching:");
    11.         for (uint i = 0; i < calls; i++) TestCache();
    12.     }
    13.  
    14.     private void TestNoCache() {
    15.         Vector3 v = Vector3.zero;
    16.         Stopwatch watch = new Stopwatch();
    17.         watch.Start();
    18.         v = transform.position;
    19.         watch.Stop();
    20.         print(watch.Elapsed);
    21.         v += Vector3.one;
    22.     }
    23.  
    24.     private void TestCache() {
    25.         Vector3 v = Vector3.zero;
    26.         Stopwatch watch = new Stopwatch();
    27.         watch.Start();
    28.         v = myTransform.position;
    29.         watch.Stop();
    30.         print(watch.Elapsed);
    31.         v += Vector3.one;
    32.     }
    33. }
    Ran cached first and got the same spike, so ignore that.

    Edit:
    Did this test again, with some improvements, mainly what xVergilx suggested. Took out the spikes, calculated average and the result with 100k runs, with 100k calls each, which took like an hour to complete(totally got caught up in the 0's). The average was 1tick for cached and non cached. I wonder why it seemed faster, and if there are times where you'd want to cache Transform.
     
    Last edited: Mar 18, 2020
    xVergilx likes this.
  43. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    Benchmarking can be tricky. Especially with Unity.
    Most of the C# suggestions include:
    -- Use separate thread (not possible with main thread only methods / properties);
    -- Skip first run (because of JIT compilation time);
    -- Run multiple times with different quantity of operations to check how complexity raises;
    -- Compute std. avg. / error.
    -- Perform GC collect (in cases where lots of GC alloc involved)

    Also, its better to do benchmark on the target platform / devices.
    (unless for scientific reasons)

    First spike is probably because of JIT. So its not that valid.
    But at the same time transform is cached once you've accessed it, so its also included in the results.

    Edit:
    Also, you can also check how much time actual native caching takes, if you use loads of objects and stopwatch "myTransform = transform" on them.

    Interesting tests though.
     
    Last edited: Mar 16, 2020
  44. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    This is micromanagement of C#, where eventually the engineering to cache everything, pool everything will surpass the engineering to create this in HPC#/DOTS.
     
    PacoPeroEnGlobant likes this.
  45. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    Ofc. But unfortunately right now MonoBehaviour approch is more common than DOTS.

    So its valid to rumble a little.
     
    valentin56610 and hippocoder like this.
  46. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Yeah I'm still in Mono land but I long since gave up on optimisations like this, favouring instead just changing approach because those still make the bigger impacts (even in mono land). I used to cache transform but I never do any more.

    I guess if I'm accessing 100+ transforms per frame I already have a pretty bad setup, or need to move my code to some kind of manager pattern rather than cache per component (I would still cache of course in these situations).

    Funny you say that I realise now that I'm probably accessing transform quite a bit (jiggle bones etc). But I believe when I profile this, the real cost will come from my altering that transform rather than access.

    Alternatives to Mono are still too bleeding edge for most people's tastes around here so you are right of course!
     
    PacoPeroEnGlobant likes this.
  47. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Got to agree with hippo here. If you really are to the point where the performance of .transform matters, you should be switching across to DOTS.
     
    neonblitzer likes this.
  48. PacoPeroEnGlobant

    PacoPeroEnGlobant

    Joined:
    Jul 30, 2021
    Posts:
    2
    I support this comment so much, I'm getting really tired of seeing optimizations that are useless in practice but add to code complexity, I love how you word this, and I love the "I guess if I'm accessing 100+ transforms per frame I already have a pretty bad setup"
     
Thread Status:
Not open for further replies.