Question Alternative to if statements for updating velocity/movement?

Hi, I'm new to coding but I noticed this in playing around with a script

void Update()
{
if (Input.GetKeyDown("space"))
{
GetComponent<Rigidbody>().velocity = new Vector3(0, 5, 0);
}
}
}

which functionally allows the player to "jump" with a velocity of 5-whatevers.

My question is: relying on if statements can be computationally inefficient. Is there a better way to set up various movements and animations besides checking a bunch of if statements every frame?

 

This is an excellent example of premature optimization. If you're talking shaders or database server programming? Yeah, maybe code branching is something that's worth optimizing. However, checking for input is something that happens once per frame. In the scale of optimizing code, this is absolutely undetectable. You can have a hundred such if statements running every frame and it will still be undetectable.

On the other hand, if you have hundreds of calls to GetComponent<Rigidbody>() every frame, that might be detectable. (You'll have to run the profiler to see if you can detect it.) Store the result of GetComponent so that you don't have to call it in Update(), and the CPU time saved on those calls will dwarf the CPU cost of branching like Mount Everest dwarfs an ant.

The best way to optimize is this: Write readable code. Code being easily readable will save you time in development by minimizing confusion. When you have a reasonably sized test case, you can use the development time you've saved to run the profiler and find your bottlenecks. Your actual bottlenecks, which will not include CPU branching on this scale.

 

Okay, so generally if statements themselves are not necessarily going to bog you down, but specific things like calls to physics will.

 

Computers aren't as dumb as we like to make them seem. When a processor sees an if statement coming down the pipeline it will make a prediction of what the outcome will be and will prepare itself based off of that prediction, and it's thanks to that (and a ton of other modern features) they're not actually computationally inefficient.

Modern processors have an accuracy that is greater than 95%, and they cache commonly accessed code so even if the prediction is incorrect it's only going to take a little longer (hundreds of cycles to access memory on systems that do billions per second) the first time.

Unless you're performing a large number of them every frame you're not going to see it with physics either. On the MonoBehaviour side Unity uses NVIDIA's PhysX engine which has all kinds of performance hacks internally that are far beyond what you're going to be able to do as a beginner.

For projects that actually do need to work with large numbers of physics calls every frame the answer still isn't to make micro-optimizations like this but to instead use technologies like DOTS. Which incidentally just had it's full release.

 

How did i miss that, thank you! Now i finally have a good reason to take a deeper look at it again and return to a couple old projects i put on hold. Amazing!

 

What? Why? That’s not true.

 

It's not entirely wrong. CPUs push a long pipeline of commands through the processor before it necessarily knows the result of them. In the case of pure math that's not an issue, but when there's an if statement, the stuff either inside or outside the if statement will get executed, but the CPU doesn't know which until the if statement is evaluated. So branching can cause CPU pipelines to have to get flushed and will waste CPU cycles to do so.

It's the scale of this slowdown that is tripping up OP. It can waste CPU cycles, but it's a really small amount of CPU cycles, unless you're doing this sort of thing millions of times per second. In shader programming, yeah, that matters. In input code, not even close.

 

I mean, yes, but you are talking about levels of efficiency that barely any Unity game bothers to achieve (or should bother to achieve, if the scale is small enough), at least prior to DOTS.

 

Alright good to know, thank you for your feedback!