Which method would be faster for this? (If tree, Switch statements)

I have been working on an AI project using A* and I also decided it was time to learn about Switch statements.
While I understand switch statements are usually faster, I am unsure if this would be slower due to having to nest a second switch statement inside.

Both methods work however I'd like some feedback on which would be a better habbit/performance wise.

Spoiler: If Statements

Code (CSharp):

1.            
2. Vector2 dir = findDirectionToTarget(transform, targetTransform);
3.             if(!CloseEnoughToTargetCheck(transform, targetTransform, reachedTargetLocationOffset)){
4.                 //Move if ai is not as close as offset
5.                 dir = (path.vectorPath[1] - transform.position).normalized;
6.                 transform.rotation = Quaternion.LookRotation(Vector3.forward, dir);
7.                 rb.velocity = dir * speed;
8.             }
9.             if(CloseEnoughToTargetCheck(transform, targetTransform, reachedTargetLocationOffset) && !wallInWay(transform, targetTransform)){
10.                 //Stop moving if there is no wall in way and the offset has been reached
11.                 findDirectionToTarget(transform, targetTransform);
12.                 rb.velocity = new Vector2();
13.                 transform.rotation = Quaternion.LookRotation(Vector3.forward, dir);
14.             else{
15.                 //Keep moving even if it's closer than offset if wall is in way
16.                 dir = (path.vectorPath[1] - transform.position).normalized;
17.                 transform.rotation = Quaternion.LookRotation(Vector3.forward, dir);
18.                 rb.velocity = dir * speed;
19.             }

Spoiler: Switch Cases

Code (CSharp):

1. Vector2 dir = findDirectionToTarget(transform, targetTransform);
2.             switch(CloseEnoughToTargetCheck(transform, targetTransform, reachedTargetLocationOffset)){
3.                 case false:
4.                     dir = (path.vectorPath[1] - transform.position).normalized;
5.                     transform.rotation = Quaternion.LookRotation(Vector3.forward, dir);
6.                     rb.velocity = dir * speed;
7.                     break;
8.                 case true:
9.                     bool wallHit = wallInWay(transform ,targetTransform);
10.                     switch(wallHit){
11.                         case false:
12.                             findDirectionToTarget(transform, targetTransform);
13.                             rb.velocity = new Vector2();
14.                             transform.rotation = Quaternion.LookRotation(Vector3.forward, dir);
15.                             break;
16.                         case true:
17.                             dir = (path.vectorPath[1] - transform.position).normalized;
18.                             transform.rotation = Quaternion.LookRotation(Vector3.forward, dir);
19.                             rb.velocity = dir * speed;
20.                             break;
21.                     }
22.                     break;
23.             }

I'd appreciate any feedback!

 

Dont consider performance for such things, at all. Switch can be faster in certain situations, if the compiler can create a jump table. This is not always the case, as C# for example also allows switching over strings, where this is not possible afaik.

Use the one you find easier to work with. Any performance difference will be unnoticably small. Unless you plan to build a switch case with hundreds or thousands of entries. Performance differences, as a rule of thumb, only matter if they are worth orders of magnitude and the input range is large enough. Changing something of O(1 * 1.2) to something of O(1) is usually irrelevant. Changing something of O(n²) to O(1) can be a huge gain, but is just as irrelevant, if the n never goes above any reasonable large number, ie stays at like 10.

Absolutely do prioritize readability and maintainability over performance for such trivial issues.

 

Pay attention to what Melv and Yoreki say above. Don't wreck your codebase for silly optimizations. Just... DON'T.

DO NOT OPTIMIZE "JUST BECAUSE..." If you don't have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window -> Analysis -> Profiler

Failure to use the profiler first means you're just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

https://forum.unity.com/threads/is-...ng-square-roots-in-2021.1111063/#post-7148770

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Notes on optimizing UnityEngine.UI setups:

https://forum.unity.com/threads/how...form-data-into-an-array.1134520/#post-7289413

At a minimum you want to clearly understand what performance issues you are having:

- running too slowly?
- loading too slowly?
- using too much runtime memory?
- final bundle too large?
- too much network traffic?
- something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as "reimport all textures as 32x32 tiny textures" or "replace some complex 3D objects with cubes/capsules" to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you're properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

 

Thank you for all the feedback on this!
I appreciate it all and I especially appreciate all the tips from Kurt leaving resources.