Performance: Awake getChild(0) vs Editor Referencing

Hello there,

So far, we were accessing components of a transform with getChild(0).GetComponent() and getComponentsInChildren() in Awake call.

Another alternative is setting x and y as public variables and using editor to drag&drop references.

Which one is better in terms of performance, best practice?

1 Like

since each API call had overhead.

if you can reference in editor it’s always better.
I recommend you write your test case for those API call.
example : JacksonDunstan.com | Unity Script Performance Testing

if you asking the performance between

  • iterator transform getChild(index) + GetComponent()
  • GetComponentsInChildrens()

the GetComponentsInChildrens() are 1000++ time faster than first option.
since we didn’t know how many child transform (recursive call)
beside, GetChild() & GetComponent() were 2 API call.
and probably you didn’t count the foreach iterator on locate each transform child.

the test case :
I tested by generate a giant gameobject contain 1000 layer’s child gameobject.
and random addComponent in random child gameobject with random amount.

2 Likes

I try to only use pre set references where possible. I utilize editor scripting where drag and drop is too time consuming. MonoBehaviour.Reset is excellent for this.

One way to find out, profile it! In general using the serialization system is much more performant.

In this case i’d also say its very error prone, you cannot know without reading the code that there needs to be at least one child with a certain component. GameObject.find would be the worst case scenario, its super expensive to visit all gameobjects by name and very error prone.

1 Like

I only use GetComponent(s) and GetComponent(s)InChildren. If I need todo something like you have with GetChild i would use serialization referencing, depends on the use case though

Thank you all for the replies. I guess, as tj said, we will proceed with general serialization system. Also agree with the error proneness of the getchild methods.