koobas.hobune.stream
Performance difference between having objects in scene upon load vs instantiating after load
Is there any difference in having objects stored in a scene versus instantiating them in Awake of the scene, or are both approaches doing effectively the same thing behind the scenes?
Was wondering exactly the same recently. Good question. But somehow, I have a feeling it will be the same, give or take a few ticks.
I would actually guess not. We have very complex scenes, and instantiating (say) a thousand objects from script can cause a quite noticeable hiccup. In fact, just changing the transform hierarchy at runtime (e.g. by changing parents) is very slow. Either way, curious to hear the answer.
I'm with DannyB. That is the aim of pooling objects isn't it? Still curious though ;) Also is there a reason you ask?
@Essential, there once was a guy at Unity who knew the inner workings, unfortunately, he left...
I'd guess that one benefit to having everything in the scene as opposed to instantiating after load is that you can do an async load if stuff is already in the scene - which should avoid the game appearing to freeze while loading in assets and such. For example, we had a game where we performed LoadLevelAsync, but it would freeze up anyway because we instantiated a bunch of stuff after loading. I don't believe there is a way to asynchronously instantiate stuff?
Another $$anonymous$$or thing is that the placement of things in a scene is saved in the scene file. If you are placing A LOT of stuff, you could see your scene file size increase - and particularly on mobile this can be a bad thing. If you ins$$anonymous$$d instantiate at runtime, the scene file size can stay relatively small.
Finally, I've found instantiating after loading is good for stuff that you know must be a certain way all the time, and you don't want to worry about inconsistencies between levels - i.e. if every level must have a camera, I might just instantiate my camera prefab on level load ins$$anonymous$$d of having to place a camera manually per level and risk missing one.
In my experience, Instantiate() is never faster than pre-loading objects, but the difference is negligible in typical use. Unless you're loading in hundreds or thousands of objects, I wouldn't worry about it.
Instantiate() causes a very small performance hit, in both time and memory; it's only going to matter if you're doing a lot of it. If you're on mobile, it'll matter a bit sooner, but it's about the same deal.
If you're worried about optimization:
Find ways to pre-load more objects in the scene.
Find ways to "pool" objects, so that they can be recycled. Instead of destroying them when you're done, make them inactive and reset them when you need them again.
(When I make object pools, the important ones are still backed by Instantiate() in the event that I run out of objects.)
Sometimes, it's the best tool for the job. Like kromenak mentioned in comments, it's handy to load in prefabs that you'd like to see consistently in every scene: cameras, game managers, and the like.
I'd add to that:
Beyond any small hit for Instantiate, changing transform hierarchy in my experience incurs quite a bit of penalty for large numbers of objects, and there's no way I know to Instantiate as a child of another object. So if you have any complex kind of structure, you have to account for that. There's no changing parents when loading a scene.
Right, that's what I'm saying - that extra 'parent = X' step after the instantiation adds time to the process, and not an insignificant amount if you're instantiating hundreds or thousands of objects (which we do).
