Advantages of creating a custom Update function?

Unity Engine
, ,
1

Hey there,
I’ve heard a lot of talk about how implementing your own custom Update function into a Unity project can help reduce a lot of overhead and thus make the game a lot more performant.
In theory, this makes sense to me, but there is one part I just don’t get, and I’d love to get your wise takes on the matter -

Assume you make your own Update system out of three scripts (just like described in this guide ).
You have an interface that determines the methods your custom update logic will have.
You have a subscription system which uses Unity’s Update in order to check for all of its subscribed objects and call the custom update method on them (by looking for the interface on those objects).
Now, because this object times its updates using Unity’s, it will need to inherit from MonoBehavior, and have an object in the scene. Alright, cool.
Finally, you have an updateable class that inherits from Monobehaviour and your interface in order to attach to GameObjects in the scene and call the custom update functions.

Now, all the objects that use this custom update, don’t they inherit from a script that also has Monobehaviour?
If so, then what is the point? Doesn’t that mean that now our objects still have MonoBehaviour, with all the overhead that comes with it?

I understand the other advantages of a custom update system - you can control the order in which certain objects update, which is a huge advantage. I just don’t get how this improves performance.

Sorry for the dumb question, and thanks in advance for your answers :slight_smile:

2

I’m not sure what’s up with the guide you linked, but the way I go about it is only the manager script is a monobehaviour - all the other scripts don’t inherit from monobehaviour, they routes all the unity functionality though the manager script that lives in the scene.

some stuff like the OnCollision callbacks can’t be used like that, so some stuff are out of the question for a manager script.

1 Like
3

A MonoBehaviour itself doesn’t have any performance overhead by itself. The performance overhead comes from Unitys engine core calling any of the callbacks that a MonoBehaviour can have. If a MonoBehaviour class does not implement a certain callback, the engine won’t even try to call it. That’s why it’s important to remove any empty callbacks you don’t use.

Please keep in mind that such a custom update manager will only have benefits if you have a lot of objects. If you have around 100 objects you probably won’t notice much of a difference.

2 Likes