Question Memory arrangement from initial Hierarchy objects?

Hey what's up.

I am curious how different arrangements of GameObjects and their components in the Hierarchy affect their memory arrangement in relationship to each other. Runtime instances aren't a big concern. I am more interested in the initial Hierarchy that is built in the Editor.

For instance, does GameObject.Find(""); start searching for GameObjects from the first object in the Hierarchy? Does having two GameObjects next to each other in the Hierarchy make them reference each other's components faster? Do parents and children share any benefits from using GetComponentInChildren/Parent calls in terms of access efficiency?

I haven't found a good resource on this, but for reasons like this I am curious about how arranging GameObjects in the Hierarchy affects their memory arrangement and access efficiency.

 

This is rather deep in the implementation and thus could also change from version to version. Unlikely that you find something reliable.
If you have the need to apply find() to objects, use your own registry either with a list or a HashMap. That will likely be faster.

 

It shouldn't matter to you. Why?

Remember the first rule of GameObject.Find():

Do not use GameObject.Find();

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

More information: https://forum.unity.com/threads/why-cant-i-find-the-other-objects.1360192/#post-8581066

As to how everything is organized internally, the entire point of defining an API is to allow Unity to restructure the underlying implementation however they see fit to suit whatever their testing indicates is the best general purpose solution to performant storage of the items in question.

You're welcome to construct experiments to try and understand what this "Black Box" is doing, but I submit that you are wasting your time, and the results are likely to be wildly different on different systems.

 

Yeah it’s likely game object find iterates through the order of hierarchy that you see. And if the object has children it iterates through all the children before continuing.
But maybe you can run a test on that:

 

Aye. I only have a handful of GameObjects on start, and most of them "Find" the first GameObject in the Hierarchy, a data object.

I don't want to test it, cause I figured there would be some documentation somewhere on it. But I guess not...

 

What other order could it iterate in?

 

Actual creation order in memory perhaps. There's no strict reason why that needs to match the hierarchy.
However, find() involves string comparisons and also crossing the border to C++ if I'm not wrong. That's why it's far slower than just a hashmap lookup and cache-aware looping could not rescue much.

 

There isn't documentation because adding such documentation would not materially help any of us, and the more Unity promises in an API, the less freedom they have to innovate and improve in the future.

A thought game for you:

Let's pretend Unity version 0.1 comes out and they publish docs promising that GameObject.Find() always starts at the top of your scene and iterates linearly. You and a few other performance hounds decide to use this knowledge to shortcut some searches and make your game faster.

Unity version Y comes out years later with a name hashing system that gives them the ability to implement a 1000x improvement to the search speed of GameObject.Find().

Oh no, they documented that it searches linearly and everybody now relies on that, so they can't take advantage of that 1000x performance increase because it would break code that functioned perfectly when there were duplicate names!

Has anybody won here?

 

Stuff changes every patch. Efficiency is a constant concern for developers, regardless of future API plans. Less complicated approaches, that can be organized well, serve well.

A paragraph somewhere in the documentation to clarify some of this is barely anything to ask for. It would have even kept me from starting this post.

 

Unity has a section of the documentation with some performance recommendations.

https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity.html

Here is the entry that includes the one for limiting your use of GameObject.Find() and Object.FindObjectOfType().

https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity7.html

That said none of the information in there is going to be in-depth like you're asking for. Part of this is due to how quickly everything changes but another part is due to how slow they are to update the documentation. For that kind of information you have to pay attention to announcements, blog posts, pre-release forums, etc.

 

good point, however I view it abit like a public list or array. I can shuffle the order around.

id be somewhat suprised if it was the case that we iterate it on GO find via order of allocation of memory as a search for index would consume more memory to memorise the index hmm and say mem alloc xxxx = index 4 of our hierarchy, while mem alloc xxxx + 1 = index 9, consume more memory than changing the allocation would.