Question Is monoBehaviour.Update always called?

Is Monobehaviour.Update called even if the object doesn't implement it? That is, for each MonoBehaviour component of each gameObject in a scene, the engine will invoke it's Update, even if is empty, with everything that it entails, like the stack push/pop, register filling, instruction pointer jump, etc?

 

No. Unity only bothers calling the magic methods for a behaviour if they implement them.

 

Yes. Every existing

GameObject

's existing

Update

method will be called every frame regardless if the method is empty or not.

 

If the Monobehaviour is enabled.

 

All three are correct.
Expressed in pseudo-code to remove any remaining ambiguities:

Code (CSharp):

1. if (script.enabled && script.hasUpdateMethod)
2.     script.Update();
3.  

 

The actual question has been answered more than sufficiently. But what background does this question have? Performance concerns? Just general curiosity?

 

Exactly my thought. "Not implemented" is kinda fuzzy and not clear defined. If the method exists (even though it contains no code, is empty) it is implemented and will be called. However if the whole method is removed Unity won't even try to call it. Unity does actually analyse all the MonoBehaviour classes (probably after compiling the code) and internally remembers which classes implement which magic methods. We don't know about the exact inner workings. However we could imagine that they actually have separate buckets / lists for each of the magic methods. So when the engine is at the point where "it calls all the update methods", it would simply use that list. So any instances which do not have an Update method would not be considered at all.

That's why you should remove empty magic methods if you don't need them. Likewise certain callbacks like OnCollisionEnter and such have an "optional" Collision argument. When you define the method without that argument, Unity won't create that Collision object and don't pass it along (though in most cases you actually need it).

So Unity is quite smart about analysing the "structure of the type". However it does not analyse the content of methods. So it's up to you to remove / not implementing a certain callback when you don't need it.

 

In terms of performance, even if the method is called, it's complexity is constant O(1). In performance sense it doesn't make much difference if a single Monobehaviour internal call takes 1 or 10 or even 100 ticks. 1 GHz processor can handle a billion ticks in a second.

Cleaning up empty methods is a good idea but it's more about readability and clean code. In my opinion these are more important than performance in overall, and performance should be optimised only when you get to those tight code loops that get to higher than constant complexity.

 

What actual variing number are you base your complexity on? If it's the number of objects with this script on the time complexity is O(n) with n being the number of gameobjects with that script on. While it's true that you may have some scripts which are only attached to a single object, a lot of them are usually on objects that scale. Keep in mind that BigO only makes sense when we talk about scaling. BigO doesn't tell you anything about how long something takes, only how it scales.

You are right that in most situations having a left-over Update won't be a huge issue (unless you have millions of instances).

I probably should leave that 10k Update blog here.

 

https://www.dotnetperls.com/aggressiveinlining exists not without a reason. Constant cost != zero cost.
And like mentioned above me, 1. it's stacking in linear fashion 2. Unity's inner workings is bit more complex, than just "single call".

 

I'm building a random dungeon generator and the dungeon pieces are made from modular assets like Synty's Dungeon and I'm seeing some performance issues and i thought that one of the issues was the fact that every modular part is a GameObject with the Update method being called.

 

Well, monobehaviours get updated, not game objects. And only if they actually implement said magic method.

So, do these game objects have components with Update? If not, you're looking in the wrong place.

You should be using the profiler to determine performance problems. Don't guess, test.

 

Right, it's even possible to put the profiler in "deep profiling mode" so it actually shows every method call. However deep profiling can have a negative impact on your game, so only use it when you're investigating something particular.

 

What the others said about profiling.

As a general rule of thumb however, how many gameobjects are we talking about? There is some overhead, so Unitys default workflow is not able to handle very large amounts of gameobjects, even if they are all very simple. That's why larger projects usually combine meshes and objects together. Instead of 10000 trees you'd have a couple chunks of forest, for example. Things like that. But again, dont jump to conclusions, do profile the actual cause of performance issues for your specific project. It might be just some unnecessarily expensive calculations you are doing.

 

The algorithmic complexity of an empty Start() method is either O(1) or O(0). This applies to the algorithm and is irrespective of who runs it where and how many times, or what sort of objects this algorithm is usually attached to. And it's not my complexity but it's the complexity of the algorithm.

Not just most situations but in practice always. If you have millions of instances in a Unity game, I would be very actively seeking for other solutions. Say, if you've got a huge level with a million gameobjects, your problems won't go away by cleaning empty Update methods but you'll want to handle the overall complexity of your game by eg. reducing, combining or pooling objects, or you'll have flaky performance.

So, in your example, we can't invalidate a general principle using a marginal, unrealistic scenario.