The rightmost column is a timeline, I don’t think you can make it bigger. It will just fill up as more Addressables operations are executed. It looks like things are loading pretty quickly from that, are you sure the delay is not something in your scripts? What do your scripts look like?
Edit: Nevermind I see you posted it above. Can you try using a coroutine instead of Tasks?
yield return on the returned async operation instead. Or use the Completed event.
You can also put the operations into a list and call Addressables.ResourceManager.CreateGroupOperation which will wait for them all.
Sorry, how do I use CreateGroupOperation?
I can’t find any examples and the compiler complains that a AsyncOperationHandle cannot be converted to IResourceLocation.
Thanks, that worked. However, it takes slightly longer than the async way, around 1 second.
I’m not running anything else, except a Debug.Log statement in the Start method.
Edit: Here is a screenshot of the Addressable groups’ settings for the local strings that I’m loading:
You could try disabling asset bundle compression, it will make things larger but they should load quicker. Im not sure you will get it down by much though. Maybe wait till the next Addressables update is out and try WaitForCompletion again.
Using Uncompressed made no difference, sadly (possibly 0.05 seconds faster).
Do you know when the next Addressables update is expected? Within a week, a month, or several months?
Can I follow the bug fix progress on a bug tracker somewhere?
Edit: I can get the time down to about 600ms (which is still very slow) by selecting “Initialize synchronously” in the Localization system settings, but then the app gets stuck on GetLocalizedStringAsync, so I guess if you use that it uses WaitForCompletion internally again.
After some more testing I found that GetLocalizedString() works if I initialize the localization system and preload the strings myself. Timing the different parts I found that the initialization alone takes about a second, preloading one string table takes about 100 ms and loading the strings themselves (four of them in this case) takes about 20 ms.
I don’t know why it takes so long to do it this way, compared to just calling GetLocalizedString() and having that handle it (before the WaitForCompletion bug), but it’s clear that it’s the initialization that takes time.
Thanks for your help and I hope the bug gets fixed soon, but I can at least continue with actual development for now, only with a slow starting app.
I did notice a bug in Addressable initialization on 1.20.5. We have a fix in 1.4. Try forcing Addressables.InitializeAsync() with WaitForCompletion, before you call Localization.
Thank you! That made a difference!
The Addressables.InitializeAsync() with WaitForCompletion took ~240 ms, but now the Localization init only takes ~360 ms, so a total time of about 600 ms before preloading tables.
However, the app now gets stuck on that WaitForCompletion, so it doesn’t run if not launched from the editor.
If I call Addressables.InitializeAsync() and yield return it before the Localization init, the app works either way and is sometimes as fast as 500 ms for Localization init when started on the phone, but it then takes almost a second when launched from the editor.
I don’t know what affects it, but it’s good to know the options and I’m grateful for your help with this.
I look forward to seeing if I can get it to be faster still when the bug fixes are ready.
