From an optimization point of view, is it best practice to delete the predefined update() methods in all my C# scripts if there is no code inside them ?

On hundreds/thousands of GameObject(s) with Update() {} empty, does the game slow down ? Can they be left empty or is it better to delete them ?

  • 3
    \$\begingroup\$ What does your profiler say? \$\endgroup\$
    – user35344
    Commented Mar 24, 2020 at 17:01

1 Answer 1


As stated in the Unity Blog post 1000 Update Calls:

[If you have empty MonoBehaviour messages], all these methods will be called each frame for all your scripts, mostly doing nothing at all!

One might ask why should anyone care about an empty method? The thing is that these are the calls from native C++ land to managed C# land, they have a cost. Let’s see what this cost is.

Check out the full post for the details of all the steps Unity goes through for each script that has an Update function. But it's also a few years old, so how do we know if that still applies?

As Tyyppi_77 says, the very best way to answer "does X have a performance cost?" is to profile your game or a toy test scene with and without X, and compare the results. That way you find out the real, evidence-backed answer instantly, without waiting on hearsay from Internet strangers like me. 😉

Here's what my profiler shows when I put several hundred game objects with an empty Update in a built Unity game, using a development build (so it's possible this is optimized further in a release build)

Unity profiler screenshot, showing 678 empty updates took 0.087 ms in total

As you can see, the cost is miniscule - about a tenth of a microsecond apiece - so this likely isn't anywhere near the top of your list of optimization priorities. But since these functions are easy to delete with no risk to the rest of the behaviour of your game, it's still good code hygiene to clean up methods you're not using.

This both makes your runtime leaner and faster, and is a useful signal to the development team that this method is not a stub that needs work, but something you've actively decided is unnecessary.

The cost is significantly higher when running in-editor (closer to a fifth of a microsecond apiece in my quick test), due to the extra safety checks and instrumentation Unity uses there, so you might also consider this a slight quality-of-life improvement for your day-to-day testing work.

  • 3
    \$\begingroup\$ Wow, definitely not the answer I was expecting! :O I'm surprised the optimizer doesn't catch this. \$\endgroup\$
    – user35344
    Commented Mar 24, 2020 at 17:05
  • \$\begingroup\$ Thank you very much ! this is the answer i was looking for. \$\endgroup\$
    – Horatiu
    Commented Mar 24, 2020 at 17:06
  • \$\begingroup\$ The slowdown is due to reflection to get at the Update() call. And that part of it is unaware of whether or not there is anything in the call. \$\endgroup\$
    – Almo
    Commented Mar 24, 2020 at 17:07
  • \$\begingroup\$ @Tyyppi_77 If you had a function that calls an empty update, like void Foo() { someScript.Update(); }, then the optimizer should remove the call to Update from Foo when it realizes it's empty. But I don't think (would love to be proven wrong!) it removes the declaration of the function itself. So when Unity asks "does this script have an update method" to build its collection of updates to call, the answer is still "yes" - I'm not sure it's visible to the runtime that the method is in fact empty. \$\endgroup\$
    – DMGregory
    Commented Mar 24, 2020 at 17:09
  • 1
    \$\begingroup\$ @Almo note that Unity does not use reflection every frame to find each update it needs to call. So while finding the update method does have a cost, it's not one that would cause a consistent hit every frame. \$\endgroup\$
    – DMGregory
    Commented Mar 24, 2020 at 17:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .