Does using the FixedUpdate hook in a bunch of places have performance concerns? Should I refactor my child MonoBehaviours to just 1 parent that calls a bunch of children?
Don’t pre-optimize. If FixedUpdate is causing you issues, then look into solutions. Until that point, you are wasting time on something that may never be a problem.
Sorry, I should have asked this in the hypothetical. I don’t have an implementation currently, and I am wondering what the best practice is. Starting from scratch, is it better to initialize N different monobehaviours, or 1 monobehaviour with N child objects?
If there were any significant savings from such a trivial change, Unity would presumably already have done that optimization behind-the-scenes so that you don’t have to. There are still N functions being called either way.
You might have a single MonoBehaviour that calls all the other functions if you need to control their order of execution.
Otherwise, organize your logic in whatever way makes your program easier to understand and maintain. In most cases, optimizing the ease of development and maintenance is more important than micro-optimizing run-time performance. (Not in ALL cases, but that’s what profilers are for.)
2 Likes
I know I’m continuing to obnoxiously dodge your question, but the best practice is the one that best serves your end goal. If your end goal is to make the most efficient program possible, then this is the kind of question you should be asking. I doubt that it is your goal to make the most efficient program possible, though; I’m guessing it’s to make a game.
The reason that this distinction is important is that generally speaking, optimizations are inherently calcifying. In other words, the faster you make your program able to run, the harder it is to change things. This is the true danger of pre-optimization. If you try to make your program run fast first, then you will sacrifice the flexibility required down the line to make it a viable product.
Now, identifying the practices that best serve your end goal is incredibly difficult, and is internalized only over years of making things. This kind of pigeonholed question is not directly useful to you, except in a book-knowledge kind of way, because it doesn’t really help you to answer the larger question: What should you be doing to make your game? I would much rather answer that question. “My idea is X and I’m thinking of doing Y. Is there better way to do X than Y?”
Lecture aside, I will actually answer your original question: Generally speaking, less is more. While the Unity update system is optimized, it is doing more than what a simple loop with delegates would. It is (can be) marginally faster to use a custom update loop and manage entities yourself than it is to go through Unity’s system. However, as I tried to stress above, this difference will not be significant until you are dealing with a large number of entities. Unless you are planning on having thousands and thousands of objects at the same time all with their own update loops, it is far simpler to get something working just with the built-in magic methods.
1 Like
Thanks, these were very helpful. For reference, I will be generating these objects on the order of dozens rather than thousands, so I’ll stick with using the simple FixedUpdate calls for this need.
I’ve found that if the objects are truly “fire and forget”, then each running its own FixedUpdate is simpler. By F&F, I mean you will never need to talk to any of them again.
But having 1 FixedUpdate run them in a loop is better if you ever need to pause them, or count how many there are, or get info from them all and do something based on it, and so on. Having them talk back to some central object is too much of a pain.
1 Like
Starting from scratch, if performance were truly a concern due to the number of objects you have, I wouldn’t waste my time with a MonoBehaviour approach but would have the performance heavy objects implemented with Unity DOTS. Assuming that it isn’t impossible due to the current state of the framework it will blow away any attempt at optimizing MBs.
1 Like