Internally, Unity tracks lists of objects interested in its callbacks, such as Update, FixedUpdate and LateUpdate. Unity maintains these lists as intrusive linked lists to ensure that list updates happen in constant time. MonoBehaviour instances are added to or removed from these lists when they are enabled or disabled, respectively.
While it’s convenient to add the appropriate callbacks to the MonoBehaviour instances that require them, this becomes more inefficient as the number of callbacks grows. There is a small but significant overhead to invoking managed-code callbacks from native code. This results both in degraded frame times when invoking large numbers of per-frame methods, and in degraded instantiation times when instantiating prefabs that contain large numbers of MonoBehaviours. The instantiation overhead is due to the performance overhead of invoking Awake and OnEnable callbacks on each component in a prefabAn asset type that allows you to store a GameObject complete with components and properties. The prefab acts as a template from which you can create new object instances in the scene. More info
See in Glossary.
When the number of MonoBehaviour instances with per-frame callbacks grows into the hundreds or thousands, it’s advantageous to remove these callbacks and instead have MonoBehaviours (or even standard C# objects) attach to a global update manager singleton. This update manager singleton can then distribute Update, LateUpdate, and other callbacks to interested objects. This has the additional benefit of allowing code to unsubscribe from callbacks when they otherwise no-op, thereby reducing the number of functions that must be called each frame.
The greatest saving is usually realized by eliminating callbacks which rarely execute. Consider the following pseudo-code:
void Update() {
if(!someVeryRareCondition) { return; }
// … some operation …
}
If there are large numbers of MonoBehaviours with Update callbacks similar to the previous, then a significant amount of the time consumed running Update callbacks is spent switching between native and managed code domains for MonoBehaviour execution that then exit immediately. If these classes instead subscribe to a global Update Manager only while someVeryRareCondition is true, and unsubscribe thereafter, then less time is spent both on switching code domains and evaluating the rare condition.
Did you find this page useful? Please give it a rating:
Thanks for rating this page!
What kind of problem would you like to report?
Thanks for letting us know! This page has been marked for review based on your feedback.
If you have time, you can provide more information to help us fix the problem faster.
Provide more information
You've told us this page needs code samples. If you'd like to help us further, you could provide a code sample, or tell us about what kind of code sample you'd like to see:
You've told us there are code samples on this page which don't work. If you know how to fix it, or have something better we could use instead, please let us know:
You've told us there is information missing from this page. Please tell us more about what's missing:
You've told us there is incorrect information on this page. If you know what we should change to make it correct, please tell us:
You've told us this page has unclear or confusing information. Please tell us more about what you found unclear or confusing, or let us know how we could make it clearer:
You've told us there is a spelling or grammar error on this page. Please tell us what's wrong:
You've told us this page has a problem. Please tell us more about what's wrong:
Thank you for helping to make the Unity documentation better!
Your feedback has been submitted as a ticket for our documentation team to review.
We are not able to reply to every ticket submitted.