Lots of caching in 1 Awake() function vs 1 call per Awake() on multiple GameObjects

Scripting
1

I used to look for and cache references to other GameObjects from 1 main Awake() function, for example in my HUDManager class, I would search for all my HUD GameObjects in its Awake() function and cache them to separate variables.

Since then, I created a new class called “SelfRegisterToManager” which takes the GameObject it’s attached to, and “Registers” it to the chosen Manager. I put “SelfRegisterToManager” on all my HUD GameObjects, and in its Awake() function, I call the chosen Manager’s “Registering” function and cache the GameObject, for example:

// On my Camera HUD object
Managers.HUDManager.RegisterGameObject( this.gameObject, hudType.CAMERA, this.gameObject.active );

// On my Laptime HUD object
Managers.HUDManager.RegisterGameObject( this.gameObject, hudType.LAPTIME, this.gameObject.active );

// On my Menus HUD object
Managers.HUDManager.RegisterGameObject( this.gameObject, hudType.MENU, this.gameObject.active );

// On my PowerUp HUD object
Managers.HUDManager.RegisterGameObject( this.gameObject, hudType.POWERUP, this.gameObject.active );

// etc...

So, every HUD object that has the “SelfRegisterToManager” script attached to it calls the “RegisterGameObject” function from whichever Manager it is talking to, and caches itself.

Lately, I have noticed that my level load times have increased, and I am wondering if it is related to how I am “caching” objects now, using the “SelfRegisterToManager” class? Like I said, before, I used to do all the caching in the Manager’s Awake() function, and now, I do all the caching from each object itself…which is the same amount of lookups, but not all in 1 place.

I hope I was able to explain what I’m doing and what I am asking without too much confusion…am I slowing down my level load times by caching my HUD objects this way, compare to caching them all in the Manager’s Awake() function?

Thanks for your time!
Stephane

2

Stephane,

I would say “maybe.” I think it really depends on how many objects you are registering (10s, 100s, 1000s?) and how the RegisterGameObject method is implemented. But unless you’re registering a LOT LOT of objects, or the RegisterGameObject method does something silly like get data from a webserver or access a file, then no, I wouldn’t think it would have much impact on load times. Did you maybe add some big textures to your project or otherwise change your art assets?

Cheers!
Cahman

3

It’s the same number of lookups, but you’re doing it from a larger number of components. To have those components perform their lookups each of them has to be instantiated and receive a message at the bare minimum.

Having said that, I still wouldn’t expect that to take particularly long. Just how large an increase are we talking about? I’d expect anything more than tenths of a second to be coming from the actual loading of data rather than anything trivial(ish) you’re doing in your code. Searching for GameObjects and/or Components isn’t cheap as far as doing things per-frame (in the Update loop) is concerned, but if you’re doing them once off you need to be doing a lot of it for it to become noticeable to a person. (Something that takes a tenth of a second isn’t an issue at all at load time, it’s a huge issue if you’re doing it each frame.)

4

Hey guys, thanks for your replies!
So I finally figured out what the problem was, and it had nothing to do with the above. It was the Substance Procedural Material I was using, they changed the way it is being implemented on Mobile devices in 4.1 (Substances now work with mobiles), and the “problem” was that my Substance was being compiled on level load and then cached, which is why only the first level load was having loading times issues.

To go back to the above though, no I am not registering many objects, maybe 10-12 HUD objects, 3-5 Control objects and 3 Camera objects. They all have the same “SelfRegisterToManager” script attached, and each registers to their own Manager. The “RegisterGameObject” function doesn’t do anything fancy, it just adds those objects and some of their components to a custom Object, defined within the same class.

The components/objects in question are already instantiated before the scene loads, or are being loaded via Application.LoadLevelAdditive().

What I like about this method is that if I create a new HUD object for example, I don’t have to add another line of code to my HUDManager’s Awake() function in order to look for and cache that new object. I just had the “SelfRegisterToManager” script to it, select which Manager it belongs to and voila. But if it’s gonna slow things down a bunch (which apparently it doesn’t since I am not registering that many objects) that I would get rid of it and find another way to automate the reference-caching…

Thanks guys!
Stephane

5

It won’t slow things down by any amount you’re going to notice.

What are you using the cached references for?