Tips to improve performance switching collections?

As my app has grown, I’ve noticed that sometimes (not always) there is a 500-1000ms delay between switching collection proxies. Are there any tips to improve performance of loading collection proxies (maybe loading in the background ahead of time)? Or other “gotchas” that I can look at to decrease the time it takes to load the collection?

Thanks!

Use async loading and preload if possible.

2 Likes

Exactly. When you load a collection proxy you can do it either synchronously via the load message or asynchronously via the async_load message. Now, in both cases it will load all of the assets contained in the collection that isn’t already loaded (some assets could be shared between multiple collections).

If you have a large collection with many atlases, factories, collection factories and so on it can still take some time to load it all. The solution with regard to factories is to tick the Load Dynamically checkbox of thee factory component and then use factory.get_status() and factory.load() (and equivalent for collection factories) to load the resources needed by the factory at a later time. Using this approach can drastically reduce the time it takes to load a collection. It also has the added benefit of conserving memory in the case where not all factories are used in a single run.

6 Likes

Is there a way to run a “init” function after re enabling a collection proxy?

Here’s my use case: loading the proxies takes a while, but once they are loaded I can use msg.post(proxy, "disable") and msg.post(proxy, "enable") to switch between them very quickly.

However, I need to update my state when they are enabled. I tried listening to an “enable” message, but that doesn’t appear to be fired. Is there an event I can listen to when a collection proxy is re-enabled, or another way to specify a function to run on the collection itself when the collection proxy is enabled?

Enabling a collection is instantaneous. There is no delay involved (or maybe just one frame).

Isn’t the init() function of scripts called when the collection is enabled, or is the init() function called when the collection has finished loading? I’m a bit uncertain to be honest, but you should be able to do a quick test to verify this.

Ah, I talked to Mathias and made some tests. What you want to do is this:

-- this will call init() on scripts and enable the collection
msg.post("#proxy", "init") -- this can be ignored. "enable" will also call "init"
msg.post("#proxy", "enable")

-- this will call final() on scripts and disable the collection
msg.post("#proxy", "final")
msg.post("#proxy", "disable") -- note that "disable" will not generate a "final" message ("unload" will though)

One could argue that a “disable” message should generate a “final” message to get a 1:1 correlation between “enable” and “disable”. Created ticket DEF-3101

3 Likes

Just to be clear, “disable” is not the same as “unload”, correct? I know init() is called when enabling a collection for the first time, but will it also be called if it has previously been disable()-ed?

They are two completely different things. An unloaded collection is completely unloaded (hence the name) from memory. A disabled collection will still use the memory but no lifecycle functions will be called on any of the components, meaning that scripts will not run (or react to messages), animations will not play etc.

Yes, if you post a “final” message before “disable”.