Will delegating a single Update() method gain performance?

I know having a lot of Updates will decrease performance.I wonder if it possible to increase performance by delegating single Update method. Something like this:

Code (CSharp):

1.  
2. class SingleUpdate : MonoBehaviour {
3.     public delegate void UpdateDel();
4.     public static UpdateDel UpdateHandler;
5.     void Update(){
6.         if(UpdateHandler != null)
7.             UpdateHandler();
8.     }
9. }
10. class Subscriber1 : MonoBehaviour{
11.     void Start(){
12.         SingleUpdate.UpdateHandler += SomeMethod;
13.     }
14.  
15.     void SomeMethod(){}
16. }
17. class Subscriber2 : MonoBehaviour{
18.     void Start(){
19.         SingleUpdate.UpdateHandler += SomeMethod;
20.     }
21.  
22.     void SomeMethod(){}
23. }

 

If you want to know for yourself, try creating a test that compares them

 

I have heard that does make it ever so slightly faster somewhere, but yeah, give it a try lol. The main benefit of that I see is changing how often they're updated on the fly. So halfing the frequency or more when you need.

 

I'm guessing the op is one of those guys who just can't bring himself to finish a game. Being a bit rude here to make a point. Stop doing this. Let it be a problem first.

 

Be aware that using such a simplified system could save some performance, but you totally ruin the update order for behaviours.

Suppose you're using MB1, MB2 and MB3 and all the instances of those MonoBehaviours subscribe directly to the update manager.
What happens is that you may have subscribed with instances of the first behaviour, following instances of the second, following instances of the third. Suddenly, you instantiate or activate instances of MB1, they subscribe again and do no longer update before instances of MB2 and MB3.

This may or may not be a problem, but I wouldn't change the system too much as this might turn out to be problematic at a later point in time.
I'd definitely try to update instances of a particular MB in one run, no matter when they come alive... Just like Unity does. That's where subsystems become handy - but it takes some time to get a well-working alternative which avoids all the pitfalls you could run into.

In the end, you'll need to benchmark this anyway. This does usually only result in noticeable (if at all) performance gains when you're dealing with a lot behaviour instances that require frequent updates.

 

@hippocoder what did you find rude? Did I miss something or did you maybe confuse this with another post?

Unity itself had a blog how you can gain performance by having only 1 update in monobehaviour ticking a customUpdate in any other classes... there are many ways to implement this.

But as others said, it’s a micro optimization that is only required if you run out of frame time and have optimized pretty everything else. Using unity “magic” update has also advantages I.e. no need to deregister destroyed objects, etc...

It’s a case by case decision - once the game is ready Andy you have performance issues

 

@Suddoha Thanks for comprehensive answer!

 

He's referring to his own post, as the OP is likely to get stuck in development due to premature optimizations...

 

@Suddoha And actually he's right. I actually have got stuck with my first game.

 

Make it work, make it right, then make it fast.

If it works, keep moving. No need to get ahead of yourself, it's probably just going to end up wasting time.

 

Yep, not intending to wound but to see you progress. This is because Unity is a moving target: even the optimisations will change. So you really sort of need to move forward blocking out large areas of the game. Bet it doesn't even get slow.

 

Yeah, i got it, Thanks for your advice.

 

https://unity3d.com/learn/tutorials...ng-performance-problems-using-profiler-window
https://unity3d.com/learn/tutorials/temas/performance-optimization/profiler-window

just in case

 

I'll weigh in because I like optimization talk just for the joy of it.

My understanding is no. Whatever overhead you improve from consolidating the Updates will likely be lost by the overhead of the delegate. Of course, if you're getting enough of them grouped, you might compensate the loss, but you'll still be paying for it with development management.

 

Yeah, that's what i'd been thinking about, delegates bring in their own overhead by calling methods indirectly. But anyway, as others said it's not worth it, since it's micro-optimization.

 

The best way to micro-optimize the update if you keep only one GO which has an Update and it calls in _directly_ without virtual calls and delegates and everything in other custom update methods.

My hobby projects actually do this. I have an internal and central SO and it has the Tick() method, which directly calls every other Tick()-s in a predefined order.

But if you're just building an application and you don't create an entire framework for it, and teach everyone else on your project how to use these, just use the standard Update()-s and when you actually hit the performance problem, start to optimize on the way you can get most gain with least work.