Instance or GetComponent?

Unity Engine
,
1

Hello, i want to ask i have a script named “x” and almost every time i need to access to the script. Because i instantiate prefabs in game so these prefabs needs to get “x” and i am using.

private x xScript;
private GameObject xScriptAttachedObject;

private void Awake()
{
    xScriptAttachedObject = GameObject.Find("xScriptAttachedObject");
}

private void OnEnable()
{
    xScript = xScriptAttachedObject.GetComponent<x>;
}

So i look for a better way and find make an instance. So i added this to my “x” script;

public static x Instance;

private void Awake()
{
     Instance = this;
}

And my question is; Is second way better than first one? And using the second way cause a problem in future?

2

So you know, here’s how to post code on the forums:

3

Done.

1 Like
4

The general consensus is that you should avoid trying to find a game object by name if you can help it.

It looks like what you are trying to do is a Singleton. If you google you can find examples of how to code this in a monobehavior. It’s essentially the same thing you did in your second example, except people also like add code to ensure that there is never more than one instance at a time.

If you were to accidentally create two game objects with that same script, Instance will be set to which ever instance initialized last.

5

Actually i am obsessed with optimization side. Approx. 50 prefabs will instantiating same time. As i know using GetComponent and GameObject.Find slower than instance.

Long story short, i need to get the some data from “x” script for prefabs. Which way is better to do this?

6

I’ve worked in codebases like that. It’s a DISASTER.

DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window → Analysis → Profiler

Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

https://discussions.unity.com/t/841163/2

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Notes on optimizing UnityEngine.UI setups:

https://discussions.unity.com/t/846847/2

At a minimum you want to clearly understand what performance issues you are having:

  • running too slowly?
  • loading too slowly?
  • using too much runtime memory?
  • final bundle too large?
  • too much network traffic?
  • something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

1 Like
7

The either look up the means to do a singleton, or just have the object instantiating these prefabs have a reference to the object they need and pass it through after instantiating.

8

I recommend breaking this habit as soon as possible as it just leads to reduced productivity for what is almost always an unnoticeable performance improvement. Very rarely will it lead to anything that matters and without proper profiling it can even lead to a reduction in performance.

That said if you’re convinced everything must be optimized you should be trying to do as much as possible in DOTS not MonoBehaviours. DOTS is a framework that is designed to be highly optimized out of the gate whereas a lot of their code based around MonoBehaviours is made for ease of development not maximum efficiency.

Just as an example I remember a video a number of years ago by one of the engineers responsible for assisting companies with optimizing their projects that mentioned Unity UI was dependent on Camera.main which was just FindObjectsByTag under the hood. If you’re not aware the Find methods are known for very poor performance.

1 Like
9

Rather than being so “obsessed with optimization,” I suggest you remember the first rule of GameObject.Find():

Do not use GameObject.Find();

More information: https://starmanta.gitbooks.io/unitytipsredux/content/first-question.html