Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

Is creating GameObjects and AddComponent at runtime performance intensive?

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

  1. astracat111

    astracat111

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

    Code (CSharp):
    1.  
    2. //An example...
    3. for (int x = 0; x < 5; x++) {
    4.    GameObject newGameObject = new GameObject();
    5.    newGameObject.name = "ImANewGuy" + "_" + x;
    6.    newGameObject.transform.parent = this.gameObject.transform;
    7.  
    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

    methos5k

    Joined:
    Aug 3, 2015
    Posts:
    8,713
    The best way to measure is to profile..
     
  3. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    692
    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

    astracat111

    Joined:
    Sep 21, 2016
    Posts:
    501
    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

    Leonetienne500

    Joined:
    Dec 5, 2016
    Posts:
    34
    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

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    4,104
    Nooope.

    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.