GameObject.Find("MyObject", true)

Hi,
Why don’t we have an override version of GameObject.Find ?
as GameObject.Find(“MyObject”, true) (and true for “Find inactive”)
We desperately need it…:(:face_with_spiral_eyes::hushed::sweat_smile:

Remember the first rule of GameObject.Find():

Do not use GameObject.Find();

More information: Regarding GameObject.Find · UnityTipsRedux

1 Like

thanks

I agree not to use it in releases.

I use it for some tests in which from scene I go around for others to perform functions (to test their effectiveness) and then I am forced to use it (only for tests performed in the editor, they are not included in the release).

To find an inactive object I use this:
FindObjectsOfType(true).First(f => f.activeInHierarchy == false && f.name == "Name_GameObject ")

1 Like

thanks a lot, but do you know what also they say “Don’t use linq it is also not performant”

I believe GameObject.Find() & others similar to it, were optimized quite a bit in a recent update. Maybe 2020.2 or 2021.1.

Well they’re correct, in certain circumstances. Linq causes quite a lot of garbage, and should be used with caution. I generally only use Linq for Editor scripts.

Even so, there’s better and far, far, more performance ways to get a reference to something.

I state that I am not an expert.

As for the GameObject.Find in addition to the performance, I have never taken it into consideration for the logic, which to me is confusing and I don’t like it. I prefer to create a reference and connect it via drag and drop than to search for an object by name which can then be modified (as I said before I use it in tests because I have to look for certain objects in other scenes).

I say this because from here I draw my personal reasoning on linq. Also I have often read that it is not the best for performance, but from a syntax point of view, it is intuitive for me to understand and it reduces the written code. I think its use depends on what you want to do. Because it will also be slower but we are talking about speed that for most of the calculations the difference is not observed. I’ve always used linq and never had any performance issues, then it’s up to you. Maybe if you have to do many, many, many calculations in an instant and you see a slight delay, do a test with linq and one without, and see if it solves the problem.

As for the line of code I wrote above, as you can see I got the object in a single line with a code that is easy to read when you get used to using expressions with lambda.
If I hadn’t used linq, I would have had to save the array of objects, iterate it, compare each single value, and then use the value (ie more lines of code and less readable code).