koobas.hobune.stream
Instantiating in Awake() v Setting up prefab instances in Editor performance difference?
I'm writing a system that requires a lot of instances of a prefab to be created in the Awake() function when a scene loads. It got me wondering whether or not I should write some editor code to create all of these prefab instances in the editor, so that they're already in the scene before I hit play and don't have to be instantiated in Awake().
So, my question is - is there a difference in performance between Instantiating instances of a prefab in the Awake() function, versus manually adding those instances of the prefab to the scene in the editor before hitting play?
I would think that manually adding a large amount of prefab instances to a scene in the editor might remove slowdown in the Awake() function when you hit play in the editor. But, in the final build of the application, the prefab instances have to get loaded either way, right? So would it not make a difference in the end?
I'm going to do some tests myself, I'm just curious if there's a commonly known best practice for performance in this situation (Set up prefab instances in the editor, or instantiate them in Awake()).
Thanks for any responses.
Matt
Firsty, you cant create prefabs at runtime, im guessing you need to instantiate prefabs at runtime.
Secondly, editor scripts wont work after standalone builds.
Thridly, instantiating things in an wake function is perfectly normal, cos awake is like a constructor for monobehaviours.
$$anonymous$$ay i ask how much time it takes to instatiate those prefabs, and how many prefabs you are instatiating?
Firsty, you cant create prefabs at runtime, im guessing you need to instantiate prefabs at runtime. Secondly, editor scripts wont work after standalone builds.
OP does not want to create prefabs nor having the editor scripts in the final build, he's asking whether he should have an editor script to instantiate the prefabs in the editor (without the game even started) so as to have the gameObject before pressing play, or if instantiating the prefabs in a standard $$anonymous$$onoBehaviour's Awake function is fine.
Spot on Hellium :).
$$anonymous$$enyus - I need to create thousands of instances of a few different Prefabs.
I think it's an interesting topic. $$anonymous$$eep us posted with the results of your tests.
The question is if the engine has an optmized method to load the scene, is the process inline or is it parallel, on top of that there is the matter of Deserialiazation which occure for each "existing" object. So in case the objects of a scene created inline, runtime Instantiation should be faster.
If you run any test run them on builds and not in the editor.
Hello @mastik53,
I think it is better to create all perfab instance in the editor.
You right when you said this prefab, will be instantiate by the application anyway. But creating the prefab in the Awake() will create a freeze the first frames after you hit the play button.
Sometimes you can't create the objects in the editor, because it depends the players choice or settings. But when you can create it before the game start : do it, because you can find way to optimize the loading of your scene, but when you instantiate a gameobject you can't do anything to improve the time it takes.
I notice when I got a lot of the same prefab in scene it is often because I'm looking to place some data on the world. And in this case you can simply save all this data in a file and read it on runtime. Then when you hit play button, you just have to load the data from the file. So you don't have to create new instance on the start.
You can look deeper to the Object Pooling pattern if you have to create a lot of instance in runtime.
I hope it will help you Regards,
You right when you said this prefab, will be instantiate by the application anyway. But creating the prefab in the Awake() will create a freeze the first frames after you hit the play button.
How could instantiating in Awake "freeze the first frames"? What does that mean anyway? If it's frozen then there are no frames.
If what you mean is just that the first frame will be a long one then fair enough. But like you say, all those things have to be instantiated anyway. So why do you think that there might be more of a slowing down if you instantiate prefabs? Why isn't that first frame equally slow in both ways of doing things?
It is my thought, and I'm not a specialist of the question.
But the way I think about that is : If you create the instance of your prefab in the awake, then the lifecycle of those prefab we'll start after the Awake that create the instances. So the scene first frame will look like that : - play the Awake() of the $$anonymous$$onoBehavior - find the Awake() of you spawner - create your hundred of new GameObject - play the Awake of the new GameObject you create - Play the Start() of all your $$anonymous$$onoBehavior
If every things is already created in the scene, I did the test, it is a little bit faster, but the difference is not obvious. And even if it is the same time, if you create the object in the Awake you have to take care that your script will not be instantiate after the Awake, the script is not twice in the scene, the script have to be activate, you have to compile the project if you want to change the position or anythings else on your instantiate GameObject..ect..
I think we can argue on the fact that create many object during the play mode or before is the same cost for performance, but in fact it is easier to manage object that are already created in the scene. Again it is my opinion
I think you've made a very good point. Instantiating the prefabs at runtime(whether in Awake or Start or whatever) does impact on the order in which things happen. For me this is a massive plus as it means I'm in control of when they happen. The things you seem to think of as problems with that (needing to keep track of things) to me are advantages - I want to be in control.
It also means that, by getting the configuration from a ScriptableObject (or whatever) I can easily change the set-up without needing to recompile.
If I understand right, you're suggesting that instantiating at runtime means that you have to rebuild if you wanted to move anything. The truth is the exact opposite. If you move things by doing it in the hierarchy and saving the scenefile, that means you have to rebuild. But if ins$$anonymous$$d of saving the scenefile, you save the current positions to a ScriptableObject - one which your code uses when it sets things up - then you can change the configuration without needing to rebuild.
It also means that one can make ones assets nicely granular you can split the configuration up into logically connected groups (ie multiple ScriptableObjects). If you keep everything in the scene file then you've got a huge and varied mix of information there - makes maintaining different versions a nightmare. And of course more granularity is good for version control and especially if working collaboratively.
I think what I'm saying is that for me, the benefits of doing things at runtime with $$anonymous$$imal scene files far outweigh any small effects there may be on the time it takes to load a scene.
Also of course it goes without saying that any difference is going to be small in comparison to the amount of time it takes to actually do the instantiations.
