good one <a href="https://www.lyricsauto.com">lyricsauto</a>

This is not good. Think about how many people are writing Editor code are calling GetComponent() and then checking for null. For example: Fabric Audio Editor code is causing a huge perf hitch for us because of this problem. Our designers need to do audio timing adjustments in the Editor, not at runtime (that's would be an unacceptable workflow). Editor performance matters, folks. Bad editor performance => wasted development time and a lot of money.

If these old posts have anything to do with the problem...
http//:answers.unity3d.com/…/-garbage-when-the-comp.html
http//:answers.unity3d.com/…/component-makes-05k-gc.html

...then GetComponent() is using exception handling to handle something that is pretty darn normal - Dictionary (etc.) lookup. i.e. this isn't an 'exception'.

And if it's throwing exceptions, I'm not seeing them in my console or Editor log or the Profiler, with all verbose logging player settings on max - unless I'm missing something. So, please report the exception so we can find the problems in our/others code.

Unfortunately, GetComponent() is something people habitually call inside the high-frequency callbacks, like MonoBehaviour.Update(), instead of caching results, using serialized fields, etc. And there are numerous snippets on the web that lead them to believe that this is desirable/normal. Even more reason to make sure that the method family is as tight as possible.

I would urge the Unity folks to reconsider this behavior. At a bare minimum, the difference between runtime and editor behaviors needs to be documented and we need some logging to pester Devs into looking at their GetComponent() usage patterns.

- thanks

public static class GameObjectExtension
{
static List<Component> m_ComponentCache = new List<Component>();

public static Component GetComponentNoAlloc(this GameObject @this, System.Type componentType)
{
@this.GetComponents(componentType, m_ComponentCache);

var component = m_ComponentCache.Count > 0 ? m_ComponentCache[0] : null;

m_ComponentCache.Clear();

return component;
}
}

@LJMEIJER, my mistake you are correct. Verified that GC alloc is 0 bytes on iOS for GetComponent.

If calling GetComponent allocates because it is considered unexpected behavior when a component does not exist, would it instead be possible to add a "HasComponent" or a "TryGetComponent" method? I often use GetComponent to check for the existence of a component and adding either of these functions would allow me to check for existence without causing any memory allocation.

This did come up before and it turned out that there is some behaviour here that is *only* in the Editor - a wrapper object is created as part of making MissingComponentException work, but in a build the wrapper isn't created (and you just get a NullReferenceException instead).

Can anyone confirm that this is actually happening in builds? If so then it's something new...

This was actually triggering a crash on iOS for me. NGUI uses GetComponent() extensively on disable/enable of UI Panels. When a UI Panel with many children was enabled/disabled several times before the GC, it created enough garbage (~20MB) to crash the app.

Verified this occurs on 4.3.4. The GC Alloc size I am seeing is large (0.6KB) each time GetComponent() is called and returns null. This can add up fast.