UPDATE / DISCLAIMER: This solution isn’t likely to work as well in newer mobile titles as physics is much more widely used than it used to be. Back in the old days, I wasn’t using much physics at all but things have changed over the years. In any case, FixedUpdate isn’t a great option for using slower loops anymore. I’ll have a new and updated article about timed functions soon to replace this post! – Mel
Merry Christmas! =)
So, I thought I’d write a Christmas blog about optimizing the Update Function in a really easy way that even a Unity beginner can implement. As I’m sure that some of you hardcore people out there will probably be coding today, you may find this information useful!
Moving on .. I think most Unity beginners and even some more experienced users really put too much into their Update() method. When we’re learning the software, we kind of get psychologically used to putting things in the Update function and we like to think of FixedUpdate() as this weird scary Physics loop that we don’t quite understand and don’t want to touch.
About Unity’s Update Loops
The first thing to realize is that the standard Update function as well as LateUpdate are quite performance hungry. This is because Update usually runs at around 30 – 60 times per second ( depending on your FPS setting ), whereas FixedUpdate is set to run at fixed intervals. By default, the difference isn’t very noticeable. But, Unity allows you to tweak FixedUpdate to run at exactly the rate that you want.
An Unconventional Solution
If your game isn’t dependant on silky smooth real-time physics, you can SLOW DOWN the FixedUpdate loop which will essentially allow you to run your code less often and typically boost your FPS. A trick I use a lot for my AI routines ( especially on mobile ) is to slow down this rate for a massive FPS boost. All you need to do, is swap out the code from the Update function, to the FixedUpdate function!
How To Tweak FixedUpdate
You’ll find this inspector in the Unity Time Manager.
The above are the default values. The “Fixed Timestep” variable is set at 0.02 ms, which means it will run 50 times per second out of the box. That’s no good, especially on mobile that’s way smoother than it needs to be. If you’re using a lot of physics in the game you’ll need to play with Fixed Timestep to get a balance between smoothness and performance. I find that 0.04 is a pretty decent middle-ground for mobile devices ( which equates to around 25 times per second ). If you’re pushing more for 0.05, that will make FixedUpdate run at 20 times per second!
What this ( theoretically ) means is:
FixedUpdate @ 0.04 (25 TPS) vs 30 FPS Update = 16.7% boost!
FixedUpdate @ 0.05 (20 TPS) vs 30 FPS Update = 33.3% boost!
FixedUpdate @ 0.04 (25 TPS) vs 60 FPS Update = 58% boost!
FixedUpdate @ 0.05 (20 TPS) vs 60 FPS Update = 66.7% boost!
* TPS = Times per second, FPS = Frames Per Second
There are other ways to split up your code ( that I may cover in future posts ) such as to use timed functions, create specialist manager objects, etc. But this is usually something that helps on many CPU intensive tasks like AI, Pathfinding, Updating Distances, etc. Think about if you really NEED to put your code in Update. Is it really necessary to update something 30+ times per second? .. Or is 20 times ( or less ) per second just as good? … The results may surprise you! =)
I hope this helps some of you!
All the best,