Interesting results! Whenever I teach optimization, I always begin with "Measure, don't guess". Measure for your platform. Measure in real world situations. Start with readable code, measure and then fix to meet a frame budget. Everything else is premature optimisation because you can't guess what optimisations the compiler will do.
at the example between Vector3.Distance vs SqrMagnitude have u try ((Random.insideUnitSphere - Random.insideUnitSphere) * MULTIPLIER).sqrMagnitude || i think it is a bit faster || 1 multiplier and 1 subdivisor faster than 2 multiplier and 1 subdivisor right ? (this is my opinion)
In my case I'm working with a compiler that literally doesn't optimize anything, this creates code that runs several orders of magnitude slower than a regular monobehavior.
Regarding the Vector3.Distance function, you're also making 2 calls to Random.insideUnitSphere, which definitely makes 1 call to sin and 2 to cos, which are also both expensive operations. But then you're calling it twice. The 6 calls to sin/cos probably dwarf the time it takes to make 1 sqrt call. That's probably why sqrt and sqrtSquared about the same time, cause the 6 trigonometric computations are taking over.
You're right. The simplified code I posted on screen shows more predictable results, but even then... not enough for me to use the less readable option. (900k iterations, 6ms and 4ms)
@@Tarodev Your simplified code is still hiding the call to operator- which *may* have an impact on performances, even if Vector3 is stack-allocated, it can trigger a call instruction to operator- and constructor. By manually writing a Vector3.SqrDistance( Vector3 a, Vector3 b ) you can have a ~40% gain in performances
I love a good caesh! Speaking of - I've heard the idea of a "Runtime Set" in a few talks regarding scriptable objects. I think it's a very nice alternative to finding objects by/of
Great video! Just remember everyone, optimization is the last thing to do! Do not try to optimize everything that you make at the start. I always suggest to make a sloppy prototype and re-write an optimized version of whole code later on.
@@umapessoa6051 I disagree. It's not the same. Multiplayer sets architectural constraints on your code, so you should do at start. Optimization should be as a result of measurement. You cannot guess what the compiler will do.
@@RobLang when your game grow big enough its pretty hard to change the base of your code to optimize it, you'll probably lose a lot of time doing it, you can't predict what the compiler will do but you can know for sure that some functions/ways of doing things shouldn't be used at all as there's more optimized options.
your clients (means gamers) are playing in unity editor? If they so, you could apply on that "tests". Anybody actually developed at least one game says that you must check optimization in release build on device only
Great video! You hit on all my potential talking points concerning usage. 😊 Another one you see a lot is using CompareTag() vs using the == operator. Speaking of, how Unity overrides the == operator is another subject worthy of a video. 😅
@@freddyspageticodeCompareTag is much faster. As well as you should avoid object.name where you can, as it crosses C++ boundary AND allocates. (i.e. if(obj1.name == obj2.name))
@@Handlessuck1 It depends on what you mean, generally C++ is faster. Both C# (when using IL2CPP), and C++ are compiled to native instructions, but due to the general nature of C#, when it "talks to" the C++ portion of the engine itself, it needs to do some marshalling and etc. (C++ doesn't really become assembly, it is compiled to native instructions, which we write as ASM so people can read it, but ASM is just another language that is converted to actual bin instructions, which are defined by the specific arch of the CPU/target) This causes it to do extra work + allocate memory that needs to be GC later. CompareTag is optimized where it does the work in the "native" part of the engine without requiring the marshalling and etc.
Great video! Haven't known them all so thanks for the knowledge! About the cached for-loop, I'll add and say that it is faster because the non-cached version, List.Count invokes the get method on the Count property each iteration
I'm not certain, but I remember back in my C# Business programming days running benchmarks in debug mode rather than prod builds gave significantly different results - and I suspect that's what you're seeing with your WebGl build the compiler can't optimise so well when it is doing a debug build - At the time (a few releases of C# ago!) for example, Linq was massively slower in a prod build but much more competitive (than a for each) an debug - however, subsequent releases improved the Linq significantly. The long and the short is - don't optimise or measure on a dev build Also - on the StringBuilder front - it's really insignificant for almost all real world cases - especially something like a game - I'd wager that concatenating the word 'score' with score.toString() 60 times a second makes almost zero impact on a prod build...
You're right about the editor/debug build. I made build using il2cpp to test. Obviously every result is much quicker, but here are the tests which did backflips: Order of operation ends up the same across the board SqrMagnitude actually does come out a bit faster (Vector3.Distance: 18. sqrMagnitude: 13. 900k iterations)
About the distance, Godot has a separate function, squareDistance, which gives you the square of the distance(as the name implies, it doesn't root the distance). The documentation says use this if you're comparing two distances, as it's faster.
@@Tarodev the reason you're not seeing a difference between distance and distanceSquared is because you're also calling Random.insideUnitSphere twice. That function calls triginometric functions 3 times, so you're doing 6 trig computations. So 6 trig computations are going to dwarf the call to 1 sqrt.
I read somewhere that they store objects with tags in a extra lookup, so they only have to iterate over that one instead of iterating over overy object, so it makes sense that it is much faster
Unity does lots of changes to the code once its compiled so I think it's important to compare results from build and editor, since honestly we should only care about what performs best in build.
An interesting point about the NonAlloc example. If you reduce the size of the preallocated array it actually does become reliably faster. I'm assuming that internally it is spending time clearing the array every time the method is called.
Not sure if you read this but I found places where you need comparisons and the editor states they are intensive for example if ( a == null ) if you instead use if ( a is null) or if (a is not null) will provide a slight performance boost though not sure why.
Your "cached for" is only slower than the foreach because you are doing two array indices access (which in C# is a function which tests the bounds every time). Also, very minor thing too, you should always use ++i instead of i++ (default to pre-increment, use post-increment only when you need post-increment behavior). You should also use unsigned integer for incremental array index loop, and use platform's native size (nint for native size integer / nuint native unsigned integer). Proper "cached for" would look like this: var values = new List(); var count = _data.Count; for (nuint i = 0; i < count; ++i) { var data = _data[i]; if (data.Value > THRESHOLD) values.Add(data.ValueTwo); } The above should at least match the foreach results (and potentially be faster) EDIT: Sadly it seems that you can only use int in for loops in unity, for some reasons other types fail to compile
For the distance you use Random.insideUnitSphere twice in each test. I have not seen the code Unity uses to calculate that, but to me it would seem obvious that its a lot more costly than calculating the distance. Making your square root comparaison completly irrelevant in the test. You could precompute the list of random vectors before the test and then only compare the square root to get a hopefully more acurate result. Edit: I did the test and if I compare the magnitude with sqrt magnitude I get for 100 000 000 iterations Distance => 1700ms Sqrt => 900ms However if I use the Distance function, forcing me to use two vectors and subtracting them in the sqrt test I get for half the number of iterations : Distance => 1700 Sqrt => 1700 so according to my computer even subtracting two vectors is enough to remove the optimization gained by avoiding the square root.
Did you see the overlay code I put on the screen at 3:24 ? Regardless, the random is being perform an equal amount of times for both tests so it shouldn't skew it too much. I did want to include that simple version on the screen just for this reason though :)
@@Tarodev The random would not skew the results, it would technically take the same time in both tests for the distance part. What would happen is the ms you show would practicly only represent the random vector generation instead of showing the time for the distance functions. For the popup you put it would seem you reuse the same 2 vectors over and over which is, I would think, prone to compiler optimizations. Since its not talked about verbally in the video I think its worth mentioning in the comments and hopefully people will know that doing tests like these have an insane amount of pitfalls and shouldn't be relied on too much.
@@XxBobTheGlitcherxX You're totally right. The benchmark I did for distance sucks, it's really just a benchmark for the 'Random.insideUnitSphere' function. But yeah even with the simplified code over 900k iterations, it comes out to 6ms and 4ms, so not enough for me to stray from the more readable Vector3.Distance.
Man Rider is awsome for this stuff as it already suggest most of these. another one you should add is the (val == nul) vs (valNull) -> cache the null to a bool
also i would love to see a performance test on IEnumarators. For example if i want smthing to be done after a period of time i could create a timer and do timer > duration -> do smthing or i could do wait for seconds in an IEnumarator. i actually dont know witch one is faster and never bothered to find out. however i usually use the timer option for frequent delays and the Ienumerator for something that is rare in my projects . Also i know there is the Awai , Async options that you show in your latest video but i have not dwelled into that yet.
It's been 15+ years since I ran this test so it may have changed but for a small number of concatenations on a string StringBuilder is slower due to the cost of creating the string builder object. But of course, the more concatenations you do on a string the more StringBuilder will help you. Another question to ask though is whether there is some other approach that will avoid having to concatenate strings in the first place. It's still a slow operation. Also on the topic of string based performance optimizations I don't know if regular expressions (System.Text.RegularExpressions.Regex) are used much in Unity but if so the creation of a Regex object is expensive in .NET so they are well worth caching.
Since most of these tests were conducted in the editor, it made me wonder if the findings translates into a standalone IL2CPP build. For example in the extern call test to C++, if the game was built using IL2CPP, won't it become a C++ to C++ call? Anyway I've conducted some tests of my own comparing editor performance vs IL2CPP standalone. Surprisingly, the performance benefits for transform caching still remains in the IL2CPP build. It's faster in the IL2CPP build (as expected), but caching the transform is about 2-3x faster than using "transform" directly. SqrMagnitude vs Magnitude yielded very similar performance in the editor, or in some runs SqrMagnitude is marginally faster. However we were surprised by the sheer speed of these functions. Calling each of them 1,000,000 times only took about 7ms. The real shocker was in the IL2CPP build. It was so fast, calling them 1,000,000 times used less than 1ms. TLDR takeaways: 1. transform caching is surprisingly faster, even in IL2CPP builds. 2. Don't think about using SqrMag vs Mag too much. They're so bloody fast, you're better off spending time optimizing other parts of your game. Just use it if u need it
I was curious about Linq vs Loop so I ran 1000 iterations on the WebGL using Chrome. My results were quite different: Linq: 833 For: 137 Cached for: 148 Foreach: 427
Really wonder why the collision check without allocation is that much slower. The computations themselves should be the same and since the benchmark executes this many times, there shouldn't be effects of the CPU caches at play here.
About strings concat. I heard that string interpolation uses in behind string builder. May it have same performance as a StringBuilder, but with pretty syntax? Oh, never mind. It's a feature of newer C# standard. I think Unity does not support it now.
In linq vs non-linq you should create list with size, because you know it. So `values = new List(_data.Count);` - this is should be faster and generate few garbage. List.Count - are slow (but not much) but array.Length - is same as call to variable.
Nice video! If you want to go deeper into the order of operation thing, it is because when you do math with a vector, that creates a new vector for the result, and scraps the original vector. so for 'vector * a * b' you get one new vector created for 'vector * a', and then another one for 'newVector * b'. You can get around that by calculating x, y and z components of the Vector seperately. So two additional tests I would propose are, for order of operations: var result = _vector3: result.x = result.x * MULTIPLIER * MULTIPLIER; result.y = result.y * MULTIPLIER * MULTIPLIER; result.z = result.z * MULTIPLIER * MULTIPLIER; for distance vs sqrMagnitude: var p1 = Random.insideUnitSphere; var p2 = Random.insideUnitSphere; p1 .x = (p1.x - p2 .x) * MULTIPLIER; p1 .y = (p1.y - p2 .y) * MULTIPLIER; p1.z = (p1.z - p2 .z) * MULTIPLIER; var value = p1.sqrMagnitude < MIN_DIST;
To the square magnitude: You should get different results. I think, square magnitude is good for checking if a vector is not 0 or similar to another vector. But to check for a set value, you need to multiply the value by itself to properly check.
For your benchmarks, I'd recommend you do a few loops (maybe 10-20) and then extrapolate the tiny, inaccurate duration to a target duration. This way you automatically have consistent test lengths :)
Just curious, how do these results stack up in a build? I tested a dictionary lookup vs an array for loop lookup and found that they were nearly the same in the editor, but the dictionary won in a build. How do all these benchmarks hold up then?
Even a single wasted millisecond per frame is a lot though since we only get a "budget" of 16.67 milliseconds per frame in order to hit 60 FPS (and even less with VR)
So in your square magnitude test it is faster to use square magnitude but not by so much that random fluctuations give you that result consistently. So not enough that it's worth giving up on readability
I could see send message being used if you don't know the class and only know the function (because you use the function on multiple cases) But even then if you aren't using interfaces you are doing it wrong.
Generating garbage often (say, on Update calls) is one of the worst thing you can do for performance. Especially on Mobile. The GC's stop-the-world functionality causes huge spikes in performance making very noticable lags. I had to cache every object in a game I worked on to leave no memory footprint to make the game run smoothly on an old Android device I had
I don't know anything about your game, of course, but if your game has lag spikes unless the memory footprint is at an absolute minimum, then that might not be the only issue
@@paulblart7378 that's true, but i noticed this using an old, mediocre Android device with very limited RAM and the game is kind of an action game GTA style meaning a lot is happening every Update(). If you have any memory allocations on every Update() in such conditions it's very likely to cause these issues.
SendMessage usage case: comp1?.func(); comp2?.func(); comp3?.func(); comp4?.func(); vs SendMessage("func", SendMessageOptions.DontRequireReceiver); Less code to maintain when adding more components that implement "func". Also useful for having more simplistic components to increase code flexibility and reuse. Edit: Also your Distance benchmark is flawed. You are creating an extra vector for DistanceSqr. Use magnitude for the first test to make it more equivalent. You should roll out your own function to do this since DistanceSqr isn't included in Unity and using math's distributive property can simplify it more.
Square magnitude is faster. "Sqrt is known to be slow" is just a huge misconception. It literally takes about 14 clock cycles as it is a native CPU instruction, whereas an addition takes 3 and a multiplication takes 4. Also here you are benchmarking a single instruction. I don't know the inner workings of the tool used but if there is almost no overhead between each loop iteration, the sqrt latency can be hidden away mostly, because of instruction level parallelism.
I think my computer is too fast for these benchmarks. I tried the Order of Operation x900,000 benchmark, and I got 2ms for each iteration. Either they heavily optimized those, or something idk
SendMessage took 3617ms and GetComponent took 219ms; Not Caching took 62ms, Cached per test took 46ms, and Fully Cached took 41ms; Vector3.Disance took 4ms and Square Magnitude 2ms; FindGameObjectsWithTag took 225ms and FindObjectOfType 2218ms; OverlapSphere 316ms and OverlapSphereNonAlloc 361ms; Camera.main 17ms, FindWithTag 156ms, FindObjectOfType 684ms, and Cached Camera 5ms; Linq 653ms, For 138ms, Cached For 140ms, and Foreach 309ms; and finally Concatenation 115ms, Builder 11ms.
Interesting results! Whenever I teach optimization, I always begin with "Measure, don't guess". Measure for your platform. Measure in real world situations. Start with readable code, measure and then fix to meet a frame budget. Everything else is premature optimisation because you can't guess what optimisations the compiler will do.
I like this and fully agree.
There's a saying... you get what you measure.
You can pretty much always guess that arrays iteration is faster than linked list.
And pretty much guess that GetComponent in Update is kinda bad
at the example between Vector3.Distance vs SqrMagnitude have u try ((Random.insideUnitSphere - Random.insideUnitSphere) * MULTIPLIER).sqrMagnitude || i think it is a bit faster || 1 multiplier and 1 subdivisor faster than 2 multiplier and 1 subdivisor right ? (this is my opinion)
In my case I'm working with a compiler that literally doesn't optimize anything, this creates code that runs several orders of magnitude slower than a regular monobehavior.
Regarding the Vector3.Distance function, you're also making 2 calls to Random.insideUnitSphere, which definitely makes 1 call to sin and 2 to cos, which are also both expensive operations. But then you're calling it twice. The 6 calls to sin/cos probably dwarf the time it takes to make 1 sqrt call. That's probably why sqrt and sqrtSquared about the same time, cause the 6 trigonometric computations are taking over.
You're right. The simplified code I posted on screen shows more predictable results, but even then... not enough for me to use the less readable option. (900k iterations, 6ms and 4ms)
Also you should be comparing it to MIN_DIST*MIN_DIST
@@television1088 if we cache MIN_DIST*MIN_DIST it will be the same thing
@@davibergamin5943 That's not something that would ever be cached except for artificially improving benchmarking.
@@Tarodev Your simplified code is still hiding the call to operator- which *may* have an impact on performances, even if Vector3 is stack-allocated, it can trigger a call instruction to operator- and constructor. By manually writing a Vector3.SqrDistance( Vector3 a, Vector3 b ) you can have a ~40% gain in performances
I love a good caesh!
Speaking of - I've heard the idea of a "Runtime Set" in a few talks regarding scriptable objects. I think it's a very nice alternative to finding objects by/of
Great video! Just remember everyone, optimization is the last thing to do! Do not try to optimize everything that you make at the start. I always suggest to make a sloppy prototype and re-write an optimized version of whole code later on.
I cannot heart this comment enough. I was planning on adding a prefix to this video regarding pre-optimization but I guess it slipped my mind.
@@Tarodev Thanks for the heart :P
I disagree, its the same as doing multiplayer games, its something that is easier/faster/better to do since the beginning.
@@umapessoa6051 I disagree. It's not the same. Multiplayer sets architectural constraints on your code, so you should do at start. Optimization should be as a result of measurement. You cannot guess what the compiler will do.
@@RobLang when your game grow big enough its pretty hard to change the base of your code to optimize it, you'll probably lose a lot of time doing it, you can't predict what the compiler will do but you can know for sure that some functions/ways of doing things shouldn't be used at all as there's more optimized options.
Love to see actual tests instead of people just repeating the same things they heard elsewhere. Good job
"Actual" means on different devices with different CPU architectures and different compiler options?
your clients (means gamers) are playing in unity editor? If they so, you could apply on that "tests". Anybody actually developed at least one game says that you must check optimization in release build on device only
Great video! You hit on all my potential talking points concerning usage. 😊
Another one you see a lot is using CompareTag() vs using the == operator. Speaking of, how Unity overrides the == operator is another subject worthy of a video. 😅
Whenever I can please you, I know I've done alright 😊
And dammit! Compare tag would have been a great one to showcase
Wait so which is faster?
@@freddyspageticodeCompareTag is much faster. As well as you should avoid object.name where you can, as it crosses C++ boundary AND allocates. (i.e. if(obj1.name == obj2.name))
@@BenVanTreese Why would c++ be slower if its going to become assembly?
@@Handlessuck1 It depends on what you mean, generally C++ is faster.
Both C# (when using IL2CPP), and C++ are compiled to native instructions,
but due to the general nature of C#, when it "talks to" the C++ portion of the engine itself, it needs to do some marshalling and etc.
(C++ doesn't really become assembly, it is compiled to native instructions, which we write as ASM so people can read it, but ASM is just another language that is converted to actual bin instructions, which are defined by the specific arch of the CPU/target)
This causes it to do extra work + allocate memory that needs to be GC later.
CompareTag is optimized where it does the work in the "native" part of the engine without requiring the marshalling and etc.
Would like to see interpolated string performance added in the string builder list.
Great video! Haven't known them all so thanks for the knowledge!
About the cached for-loop, I'll add and say that it is faster because the non-cached version, List.Count invokes the get method on the Count property each iteration
Fascinating, never knew transform wasn't a direct property and that behind the scenes it was going off and doing stuff, another quick win for caching
Bro, you deserve way more subs! Cheers 🍻
Thanks brother
Release builds will have vastly different perf than what you see in the editor (debug). Great vid.
You did all what we was wondering about. Thanks for this video!
-good UI scene btw.
Better than looking at some boring numbers in a console :)
3:53 that is super surprising to me. thanks.
Thanks for that last one, I've never seen that anywhere before.
Man, you're rocks! Thank You for your course !!! I've learned so much!!!
Woah!
And then to think that getcomponent already isn't the best thing to do a ton. Also cache the component if possible at Start!
God DAMN this is exactly my kinda video. You're incredible!! Thanks for the hard work
I'm not certain, but I remember back in my C# Business programming days running benchmarks in debug mode rather than prod builds gave significantly different results - and I suspect that's what you're seeing with your WebGl build
the compiler can't optimise so well when it is doing a debug build -
At the time (a few releases of C# ago!) for example, Linq was massively slower in a prod build but much more competitive (than a for each) an debug - however, subsequent releases improved the Linq significantly.
The long and the short is - don't optimise or measure on a dev build
Also - on the StringBuilder front - it's really insignificant for almost all real world cases - especially something like a game - I'd wager that concatenating the word 'score' with score.toString() 60 times a second makes almost zero impact on a prod build...
You're right about the editor/debug build. I made build using il2cpp to test. Obviously every result is much quicker, but here are the tests which did backflips:
Order of operation ends up the same across the board
SqrMagnitude actually does come out a bit faster (Vector3.Distance: 18. sqrMagnitude: 13. 900k iterations)
Order of operation is the only one I did not know about. Glad you added it too.
About the distance, Godot has a separate function, squareDistance, which gives you the square of the distance(as the name implies, it doesn't root the distance). The documentation says use this if you're comparing two distances, as it's faster.
Godot has some lovely little helper functions it seems
@@Tarodev the reason you're not seeing a difference between distance and distanceSquared is because you're also calling Random.insideUnitSphere twice. That function calls triginometric functions 3 times, so you're doing 6 trig computations. So 6 trig computations are going to dwarf the call to 1 sqrt.
You are doing the Lord's work. Thank you for being awesome, I always wanted to do tests like this, but I don't have time right now.
This is really interesting to see! I've been talking about a few of these recently so it's good to have a clear example to point to!
I read somewhere that they store objects with tags in a extra lookup, so they only have to iterate over that one instead of iterating over overy object, so it makes sense that it is much faster
been looking for a video like this, taro you champ
Unity does lots of changes to the code once its compiled so I think it's important to compare results from build and editor, since honestly we should only care about what performs best in build.
Phat info dump, thanks for putting in the effort.
I just found your channel and I love it. Thank you!
Can't wait to see your other videos.
Awesome video 👍! Did not know about the order of operation ! Now, need to refactor all my code XD.
Please don't. I just tried 900k iterations on a standalone build and they all came out even. It's so tiny to not even matter :)
An interesting point about the NonAlloc example. If you reduce the size of the preallocated array it actually does become reliably faster. I'm assuming that internally it is spending time clearing the array every time the method is called.
Oh wow... I had no idea about the order of operations, that's something a lot of people put in their Update methods, so it's potentially a big deal.
Not sure if you read this but I found places where you need comparisons and the editor states they are intensive for example if ( a == null ) if you instead use if ( a is null) or if (a is not null) will provide a slight performance boost though not sure why.
Your "cached for" is only slower than the foreach because you are doing two array indices access (which in C# is a function which tests the bounds every time).
Also, very minor thing too, you should always use ++i instead of i++ (default to pre-increment, use post-increment only when you need post-increment behavior).
You should also use unsigned integer for incremental array index loop, and use platform's native size (nint for native size integer / nuint native unsigned integer).
Proper "cached for" would look like this:
var values = new List();
var count = _data.Count;
for (nuint i = 0; i < count; ++i) {
var data = _data[i];
if (data.Value > THRESHOLD) values.Add(data.ValueTwo);
}
The above should at least match the foreach results (and potentially be faster)
EDIT: Sadly it seems that you can only use int in for loops in unity, for some reasons other types fail to compile
Linq vs Loop - for cached for, you should cache _data[i] for better result.
You're 100% right here
I learned more than a thing or two. Thanks!
Actually never thought of that last one before
wow, great video! always stressed about optimizations
Useful comparisons, thanks for the video!
For the distance you use Random.insideUnitSphere twice in each test. I have not seen the code Unity uses to calculate that, but to me it would seem obvious that its a lot more costly than calculating the distance. Making your square root comparaison completly irrelevant in the test.
You could precompute the list of random vectors before the test and then only compare the square root to get a hopefully more acurate result.
Edit: I did the test and if I compare the magnitude with sqrt magnitude I get for 100 000 000 iterations
Distance => 1700ms
Sqrt => 900ms
However if I use the Distance function, forcing me to use two vectors and subtracting them in the sqrt test I get for half the number of iterations :
Distance => 1700
Sqrt => 1700
so according to my computer even subtracting two vectors is enough to remove the optimization gained by avoiding the square root.
Did you see the overlay code I put on the screen at 3:24 ?
Regardless, the random is being perform an equal amount of times for both tests so it shouldn't skew it too much. I did want to include that simple version on the screen just for this reason though :)
@@Tarodev The random would not skew the results, it would technically take the same time in both tests for the distance part. What would happen is the ms you show would practicly only represent the random vector generation instead of showing the time for the distance functions. For the popup you put it would seem you reuse the same 2 vectors over and over which is, I would think, prone to compiler optimizations. Since its not talked about verbally in the video I think its worth mentioning in the comments and hopefully people will know that doing tests like these have an insane amount of pitfalls and shouldn't be relied on too much.
@@XxBobTheGlitcherxX You're totally right. The benchmark I did for distance sucks, it's really just a benchmark for the 'Random.insideUnitSphere' function. But yeah even with the simplified code over 900k iterations, it comes out to 6ms and 4ms, so not enough for me to stray from the more readable Vector3.Distance.
Man Rider is awsome for this stuff as it already suggest most of these. another one you should add is the (val == nul) vs (valNull) -> cache the null to a bool
also i would love to see a performance test on IEnumarators. For example if i want smthing to be done after a period of time i could create a timer and do timer > duration -> do smthing or i could do wait for seconds in an IEnumarator. i actually dont know witch one is faster and never bothered to find out. however i usually use the timer option for frequent delays and the Ienumerator for something that is rare in my projects . Also i know there is the Awai , Async options that you show in your latest video but i have not dwelled into that yet.
It's been 15+ years since I ran this test so it may have changed but for a small number of concatenations on a string StringBuilder is slower due to the cost of creating the string builder object. But of course, the more concatenations you do on a string the more StringBuilder will help you. Another question to ask though is whether there is some other approach that will avoid having to concatenate strings in the first place. It's still a slow operation. Also on the topic of string based performance optimizations I don't know if regular expressions (System.Text.RegularExpressions.Regex) are used much in Unity but if so the creation of a Regex object is expensive in .NET so they are well worth caching.
The NonAlloc being slower is actually a nasty bug. It's not only a lot slower, it allocates a lot of memory (that you can't see in the profiler).
this is actually very interesting
Since most of these tests were conducted in the editor, it made me wonder if the findings translates into a standalone IL2CPP build. For example in the extern call test to C++, if the game was built using IL2CPP, won't it become a C++ to C++ call?
Anyway I've conducted some tests of my own comparing editor performance vs IL2CPP standalone.
Surprisingly, the performance benefits for transform caching still remains in the IL2CPP build. It's faster in the IL2CPP build (as expected), but caching the transform is about 2-3x faster than using "transform" directly.
SqrMagnitude vs Magnitude yielded very similar performance in the editor, or in some runs SqrMagnitude is marginally faster. However we were surprised by the sheer speed of these functions. Calling each of them 1,000,000 times only took about 7ms. The real shocker was in the IL2CPP build. It was so fast, calling them 1,000,000 times used less than 1ms.
TLDR takeaways:
1. transform caching is surprisingly faster, even in IL2CPP builds.
2. Don't think about using SqrMag vs Mag too much. They're so bloody fast, you're better off spending time optimizing other parts of your game. Just use it if u need it
I was curious about Linq vs Loop so I ran 1000 iterations on the WebGL using Chrome. My results were quite different:
Linq: 833
For: 137
Cached for: 148
Foreach: 427
Really wonder why the collision check without allocation is that much slower. The computations themselves should be the same and since the benchmark executes this many times, there shouldn't be effects of the CPU caches at play here.
Fantasic content!
About strings concat. I heard that string interpolation uses in behind string builder. May it have same performance as a StringBuilder, but with pretty syntax?
Oh, never mind. It's a feature of newer C# standard. I think Unity does not support it now.
Your videos are giving me a cuteness overload 🤗😇😍
Heh, they are? 😊
@@Tarodev definitely 🥰
Thank you so much!!! It did work and took less than 5 minutes!
... What worked?
In linq vs non-linq you should create list with size, because you know it. So `values = new List(_data.Count);` - this is should be faster and generate few garbage. List.Count - are slow (but not much) but array.Length - is same as call to variable.
Nice video!
If you want to go deeper into the order of operation thing, it is because when you do math with a vector, that creates a new vector for the result, and scraps the original vector. so for 'vector * a * b' you get one new vector created for 'vector * a', and then another one for 'newVector * b'. You can get around that by calculating x, y and z components of the Vector seperately.
So two additional tests I would propose are, for order of operations:
var result = _vector3:
result.x = result.x * MULTIPLIER * MULTIPLIER;
result.y = result.y * MULTIPLIER * MULTIPLIER;
result.z = result.z * MULTIPLIER * MULTIPLIER;
for distance vs sqrMagnitude:
var p1 = Random.insideUnitSphere;
var p2 = Random.insideUnitSphere;
p1 .x = (p1.x - p2 .x) * MULTIPLIER;
p1 .y = (p1.y - p2 .y) * MULTIPLIER;
p1.z = (p1.z - p2 .z) * MULTIPLIER;
var value = p1.sqrMagnitude < MIN_DIST;
Obviously the best thing to do is result = _vector3 *(a*b);
To the square magnitude: You should get different results. I think, square magnitude is good for checking if a vector is not 0 or similar to another vector. But to check for a set value, you need to multiply the value by itself to properly check.
Thanks for tutorial, It's very helpful.
For your benchmarks, I'd recommend you do a few loops (maybe 10-20) and then extrapolate the tiny, inaccurate duration to a target duration. This way you automatically have consistent test lengths :)
How does stringbuilder for small concatenations compare to Interpolated Strings?
This such a good video, learn a lot from this.
Just curious, how do these results stack up in a build?
I tested a dictionary lookup vs an array for loop lookup and found that they were nearly the same in the editor, but the dictionary won in a build.
How do all these benchmarks hold up then?
Very informative! Thx.
He had when he "pitched down the Nice tutorialgh hats at the end of the phrase. "
Great video, as always love the hat 🍩😮
No hat today, you insufferable shiny beer can!
@@Tarodev 😄
Its important to caysh your references!
Very interesting...🧐👏
Thanks I wanna get into electronic soft.
In soft One, there is relatively little although I will say soft One has so fantastic features and I tNice tutorialnk it is going places (Rated No 2
Even a single wasted millisecond per frame is a lot though since we only get a "budget" of 16.67 milliseconds per frame in order to hit 60 FPS (and even less with VR)
2:10 can you apply this on an static class variables like calling instance?
So in your square magnitude test it is faster to use square magnitude but not by so much that random fluctuations give you that result consistently.
So not enough that it's worth giving up on readability
in contatenation there is String.Concat that ua haven't tried yet.
whats the song on the background when he speaks about Vector3.Distance and Find Objects ??
the Brockhampton - Gold remix, I cant find it, where can I find it? It's so good
How are you decompiling Unity code?
Both the Rider IDE and resharper for visual studio have a decompiler 😊
linq vs loops: what if you use linq's foreach?
I could see send message being used if you don't know the class and only know the function (because you use the function on multiple cases)
But even then if you aren't using interfaces you are doing it wrong.
Generating garbage often (say, on Update calls) is one of the worst thing you can do for performance. Especially on Mobile. The GC's stop-the-world functionality causes huge spikes in performance making very noticable lags. I had to cache every object in a game I worked on to leave no memory footprint to make the game run smoothly on an old Android device I had
I don't know anything about your game, of course, but if your game has lag spikes unless the memory footprint is at an absolute minimum, then that might not be the only issue
@@paulblart7378 that's true, but i noticed this using an old, mediocre Android device with very limited RAM and the game is kind of an action game GTA style meaning a lot is happening every Update(). If you have any memory allocations on every Update() in such conditions it's very likely to cause these issues.
nice tuto bro, that solved!
Amazing video!!
Thanks for this
Great video!
SendMessage usage case:
comp1?.func();
comp2?.func();
comp3?.func();
comp4?.func();
vs
SendMessage("func", SendMessageOptions.DontRequireReceiver);
Less code to maintain when adding more components that implement "func". Also useful for having more simplistic components to increase code flexibility and reuse.
Edit: Also your Distance benchmark is flawed. You are creating an extra vector for DistanceSqr. Use magnitude for the first test to make it more equivalent. You should roll out your own function to do this since DistanceSqr isn't included in Unity and using math's distributive property can simplify it more.
Gold
Thanks
Also sqrmagnitude precision seems to make the results very unreliable most of the time, anyone experiencing the same issue ?
Thanks for lesson
Square magnitude is faster. "Sqrt is known to be slow" is just a huge misconception. It literally takes about 14 clock cycles as it is a native CPU instruction, whereas an addition takes 3 and a multiplication takes 4.
Also here you are benchmarking a single instruction. I don't know the inner workings of the tool used but if there is almost no overhead between each loop iteration, the sqrt latency can be hidden away mostly, because of instruction level parallelism.
You become my sensei for unity. You do things we all need!
Greate video . Thanks 😎
Super useful.
Very good to know I am not doing anything I shouldn't
I was not using Vector3.Distance because literally anyone who uses Unity told me to do so.
I think my computer is too fast for these benchmarks. I tried the Order of Operation x900,000 benchmark, and I got 2ms for each iteration. Either they heavily optimized those, or something idk
SendMessage took 3617ms and GetComponent took 219ms; Not Caching took 62ms, Cached per test took 46ms, and Fully Cached took 41ms; Vector3.Disance took 4ms and Square Magnitude 2ms; FindGameObjectsWithTag took 225ms and FindObjectOfType 2218ms; OverlapSphere 316ms and OverlapSphereNonAlloc 361ms; Camera.main 17ms, FindWithTag 156ms, FindObjectOfType 684ms, and Cached Camera 5ms; Linq 653ms, For 138ms, Cached For 140ms, and Foreach 309ms; and finally Concatenation 115ms, Builder 11ms.
3:18 Whoa! How the hell did you do that? :-O
Rider has a built-in decompiler :)
Resharper for VS also provides this service.
@@Tarodev Thank you!
i want to start making soft and rapping i have an acer laptop. does soft soft co with good softs already?
but what are your specs
omg that how I feel!
working 100 %
Awesome program
Gold!
I click on instruntals and I hear no soft
I love soft soft so so so so much!
WELCO TO THE softIAN BROTHER !