|
This is more of a conscious check due to some performance issues my team has been encountering. Is there by any chance a recommended cap for the number of Components/MonoBehaviours that can be created (through AddComponent()) and removed (through Destroy()) every FixedUpdate? Of course, I am not considering the obvious "the more objects created/destroyed, the less performance". I just wanna make sure I am not getting stuck in a pipeline that i am not aware of, or if there are any good Unity practices on such subject that I could learn (besides the also obvious "the less possible objects, the better"). Thanks in advance.
(comments are locked)
|
Be the first one to answer this question
Well from my very short experience on mobile platforms, even with 15 fairly simple draw calls on the scene without optimization, destroy and instantiating prefabs has caused minor hiccups in frame rate and slight pauses that definitely shouldn't be there.
I've added and removed primitive components without too many issues. When it comes to allocating memory with prefabs though, I definitely would recommend some form of object pool that is initialized and recycled instead of using unity's instantiate and destroy.
dunno about rule-of-thumb limits on how often, but where possible, you might try disabling and enabling components rather than adding and destroying them; this would avoid any alloc/dealloc costs involved.