Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice
  2. Ever participated in one our Game Jams? Want pointers on your project? Our Evangelists will be available on Friday to give feedback. Come share your games with us!
    Dismiss Notice

Is creating GameObjects and AddComponent at runtime performance intensive?

Discussion in 'Scripting' started by astracat111, Mar 20, 2018.

  1. astracat111


    Sep 21, 2016
    I'm wondering if this kind of thing is performance intensive:

    Code (CSharp):
    2. //An example...
    3. for (int x = 0; x < 5; x++) {
    4.    GameObject newGameObject = new GameObject();
    5. = "ImANewGuy" + "_" + x;
    6.    newGameObject.transform.parent = this.gameObject.transform;
    8.    newGameObject.AddComponent<MyScript>();
    9. }
    I'm not exactly calling it every frame...but...

    I instantiate 5-6 scripts all at once this way, then the script itself when it's done destroys it's game object, so these game objects are created very temporarily just to run these instances of these scripts.

    Is it performance intensive in this way to dynamically create an empty game object so that it can run an instance of a monobehaviour script?

    I've got a very unique circumstance in where I've developed my own scripting language, so the 'MyScript' part of this is unknown and could be any script called by the text string fed in (this script doing this is an interpreter script that eats strings and spits out monobehaviour actions).
  2. methos5k


    Aug 3, 2015
    The best way to measure is to profile..
  3. Owen-Reynolds


    Feb 15, 2012
    I don't see why it's any worse than it looks -- a gameObject is just a very small class, and it's merely added/subtracted from a list. No collider, so shouldn't be redoing the global collision tree.

    But do you need all that? The advantages of monobehaviors are they can be pre-set on a gameObject, they can run coroutines (because the coroutine is attached to it and lives as long as the gameObject lives,) they can receive physics events, they can easily be located after a raycast hits a collider. Quick temp scripts on empties aren't using any of that. Regular code can do any manipulation you need.

    Even the way you have it, each could clean up after itself with Destroy(this). Then they could share a gameObject.
  4. astracat111


    Sep 21, 2016
    Gotcha, alright, this was my thought as well.

    I'm thinking that performance can take a hit with the editor overhead, which is what I'm seeing in the profiler, but that editor overhead isn't there when built so when you create a gameobject dynamically it must be just as quick as creating an instance of any other class upon runtime.
  5. Leonetienne500


    Dec 5, 2016
    No, not really. Not in this case.
    I made a chunk loader and my game had about a 50ms hickup everytime a chunk was loaded. (The chunks were created in seperate threads).

    According to the profiler, the method that creates the chunk gameobjects and adds its component only takes about 2ms to execute, but the lags were gone when i just commented out all the addcomponent code
  6. Baste


    Jan 24, 2013

    GameObjects and Components are Untiy-objects, which means that they have to be registered with the c++ side of the Unity engine. So there's a much larger overhead for creating those (cross C#/C++ border, allocate object on c++ side, return) than for just creating a plain C# object.

    Now, that doesn't mean that the overhead is large enough that you shouldn't care about it. It does mean that if this could be solved as well without creating a GameObject, you should just not create it.