Is there performance limitation to considere with monobehavior's update ?

What I mean with a simple function over one frame ;

1 : running this function each update over 100 gameobject,
VS
2 : running 100 time this function in the same update in one gameobject.

So my question is, is there a performance cost from jumping between updates to do the same job that could be done bulk in one update ?

 

Why do that, when somebody working at Unity already did it and wrote a blog post about it.

It's pretty old, 7 years by now! But the project is on GitHub. I updated and automated it a bit, and the results on my computer, on a build, using Mono:

10000 Update() calls gives a frame time of ~1.47 milliseconds
10000 calls from the manager script gives a frame time of ~0.06 milliseconds
10000 Coroutines updating with yield return null gives a frame time of ~5.45 milliseconds

So the difference on my computer is that on a very contrived example, Unity calling Update takes about 25 times longer than having an Update manager doing it.

I tried using IL2CPP instead of Mono, but IL2CPP isn't distributed with it's required dependencies and right now I can't be assed to install a bunch of random Visual Studio/C++ stuff on this computer until it works.

 

Also, to note, if you want to do a manager-like thing, but still stay in MonoBehaviour (ie. you're sane), I recommend using the PlayerLoop and create a system instead of having a MonoBehaviour manager. The MonoBehaviour manager has a lifetime tied to the scene, and has a lot of other things attached to it that you don't really care about. PlayerLoop allows you to just have a static method that gets called every frame. You can even decide where it executes in relation to Update/LateUpdate.

 

Thanks this is very helpfull