Unity Tricks – An Easy Way Of Optimizing Performance In Update()

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!

Update Performance

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,

– Mel

Mip Maps Are Over Rated In Unity3D, Save 33% Texture Memory!

Flight Unlimited Las Vegas

So, there are definitely people on both sides of the Mip Maps fence. But I’ll throw my opinion into the mix, which is on modern mobile devices right now, Mip Maps are on the most part over-rated.

The Issues

In the screenshot above taken from the Flight Unlimited Las Vegas Unity project, you can see the negative effects of NOT having Mip Maps enabled. in the far distance of the city, things seem a little more pixelated.

If you really HAVE to use Mip Maps, a better solution is to mix and match. For example, the desert area in the background DOES have mipmaps enabled because it is a single repeating texture for a massive space around the city. This makes sense, and is worth the extra memory usage for a SINGLE texture.

By turning on Mip Maps, the scene will look a little more blurry far away ( which sometimes looks better ), but this has a cost of around a 33% extra memory.

The Math

Now consider this, in the scene above, there is around 200 textures being used. If for example, each texture WITHOUT Mip Maps were 64k in memory each, that would equal 12,800k ( About 12.5MB ).  Turning ON Mip Maps would add around 33% extra memory (on a 512×512 texture) bringing the memory cost to 85.4k each. The memory would then equal 17,080k (16.7MB). That’s around a 4MB difference. That might sound insignificant when thinking about consoles or the Desktop, but on a Mobile device, that can make all the difference!


Mip Maps are definitely something to think about. If you are going to use Mip Maps, consider if you REALLY need them. Memory is a valuable commodity in mobile development, so use it wisely! =)


– Mel

Save 50% Memory From 3D Meshes in Unity

So this is a pretty awesome optimisation I discovered while I was working on Flight Unlimited Las Vegas.


The Problem

The game has a massive part of the Las Vegas area satellite-imaged as part of the flying area. In fact, it is over 130 square miles! This really causes problems on mobile devices as RAM is limited.

I did the usual things when trying to optimise memory usage. Reduced texture sizes for smaller objects, turned off mip-maps (more on that in a different post!), etc. Then I checked out the Profiler to discover something pretty interesting ..

The actual 3D meshes ( NOT the textures ) were taking up the vast majority of the RAM. I found this pretty shocking at first as most of the buildings in the game were pretty low poly. I guess the sheer amount of them stretching over 130 virtual square miles was enough! The meshes alone were taking around 40MB of RAM.

The Solution

After thinking about what might be causing this, I did something insanely effective that I’m sure many of us would skip or not think twice about.. Disable the NORMALS and TANGENTS from the Mesh.


This has certain side-effects, but luckily, none of them applied to our project.

Normals are a type of data stored in the mesh to help out real-time lights, and Tangents are used to help Shaders perform things like “bump-mapping”.

As the scene was already baked with BEAST light-mapping, the scene wasn’t going to need the normals. And the shaders we used for the environment weren’t using bump mapping so the tangents weren’t a problem either.

The result …?

Mesh Memory was brought down from 40MB to about 23MB. Almost a 50% reduction. This was the difference between iPod4 / iPad1 compatibility, which we were able to offer upon discovering this optimisation.

I’m sure some of you should find this helpful! =)

All the best,

– Mel.