New in Addressables 1.4.0: long time spent "Preparing Addressables Data" in BuildScriptFastMode

Unity Engine
1

We’ve tried upgrading from Addressables 1.3.8 to 1.4.0.

With 1.3.8, using BuildScriptFastMode (Asset Database), it takes less than 5 seconds between pressing play in the editor to having the game start.

With 1.4.0, there’s now a significant amount of time spent “Preparing Addressables Data” as it gathers assets. The start time after pressing play now takes over 15 seconds, over triple the startup time versus 1.3.8.

Is there any reason why BuildScriptFastMode needs to take so much longer now?

1 Like
2

me to,I’m about 5 seconds slower than version 1.3.8.

3

ver 1.4.0
“Preparing Addressables Data” does not finish.

4

@unity_bill Is there anything we can do to reduce editor startup time with 1.4.0?

5

Hm, this is interesting. So for 1.4 we took out a bunch of unnecessary asset gathering (mainly for dependency calculations which isn’t required in fast mode) when creating the Fast Mode content catalog. In our test project this actually made things quite a bit faster. Does anyone mind sharing their Addressables setup? Are you using a deep folder structure that you’ve added to Addressables? Do you have assets across many groups or few? I’m trying to figure out what the difference could be in our test project vs. what you guys are seeing.

6

@davidla_unity So I think that I found the culprit:

            foreach (var entry in assetGroup.entries)
            {
                EditorUtility.DisplayProgressBar($"Preparing Addressables Data ({assetGroup.Name})", entry.AssetPath, index / assetGroup.entries.Count);

It’s the call to EditorUtility.DisplayProgressBar in this for loop that’s causing a massive slowdown. For my project, if I comment-out that line, then the startup performance is restored to 1.3.8 levels.

According to an old Tweet by Unity Engineer @superpig , EditorUtility.DisplayProgressBar should be used with caution in a for loop:

2 Likes
7

Yeah, I think you’re right. I looked into it yesterday some and saw that when removing that it appeared to speed back up.

I’d like to have some sort of progress indicator so projects that could take a few seconds (or longer) don’t get stuck in that “Is the editor frozen?” mentality. But yeah the progress bar as it is now needs to be removed/changed. Thanks for the heads up.

Just curious, when entering playmode when you’re using the fast mode build script would you expect to see a progress bar of some kind when Addressables is building your catalog? Are you ok with not seeing anything and feel confident the editor isn’t hanging? Anyone feel free to chime in. I’m curious what you’d like to see.

8 
            //intentionally for not foreach so groups can be added mid-loop.
            for(int index = 0; index < aaContext.settings.groups.Count; index++)
            {
                AddressableAssetGroup assetGroup = aaContext.settings.groups[index];
                EditorUtility.DisplayProgressBar("Preparing Addressables Data", assetGroup.Name, (float)index / aaContext.settings.groups.Count);
                var errorString = ProcessGroup(assetGroup, aaContext);
                if (!string.IsNullOrEmpty(errorString))
                {
                    EditorUtility.ClearProgressBar();
                    return errorString;
                }
            }
            EditorUtility.ClearProgressBar();

This in BuildScriptBase.cs works better for me. I’ve approx 100 groups. Also, the constant flickering that happens by putting the ClearProgressBar in BuildScriptFastMode:ProcessGroup doesn’t look good on my screen.

1 Like
9

@davidla_unity For my own project, I would be okay with returning to the 1.3.8 behavior with no progress bar. Because hitting play happens all the time, anything that increases the time spent in startup would be a negative. Personally it’s acceptable if the editor “hangs” after hitting play as long as it’s under 5 seconds which is the case for me.

Perhaps another option would be a pair of console outputs:
Addressables Building Catalog: Begin…
Addressables Building Catalog: End - Elapsed 4.2 seconds

10

Glad to see we’re not the only ones with this behavior.
Concerning the display bar, I agree with others, as long as it’s not too long I don’t need to see it, but if you find a way to display one without it slowing down the whole process then why not.

Additionally, there’s another kind of progress bar unity uses for lightmapping that feels better integrated to the engine, maybe that’s an area worth looking into?

11

@MagicDesignEmerick Interesting, I’ll have to check into the one for lightmapping. In the meantime we’ve implemented the fix suggested by @rg_johnokane so hopefully that isn’t slowing anything down like the other implementation was.