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

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?

 

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

 

ver 1.4.0
"Preparing Addressables Data" does not finish.

 

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

 

@DavidUnity3d So I think that I found the culprit:

Code (CSharp):

1.             foreach (var entry in assetGroup.entries)
2.             {
3.                 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:
https://twitter.com/superpig/status/215135902211641346

 

Code (CSharp):

1.             //intentionally for not foreach so groups can be added mid-loop.
2.             for(int index = 0; index < aaContext.settings.groups.Count; index++)
3.             {
4.                 AddressableAssetGroup assetGroup = aaContext.settings.groups[index];
5.                 EditorUtility.DisplayProgressBar("Preparing Addressables Data", assetGroup.Name, (float)index / aaContext.settings.groups.Count);
6.                 var errorString = ProcessGroup(assetGroup, aaContext);
7.                 if (!string.IsNullOrEmpty(errorString))
8.                 {
9.                     EditorUtility.ClearProgressBar();
10.                     return errorString;
11.                 }
12.             }
13.             EditorUtility.ClearProgressBar();
14.  

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

 

@DavidUnity3d 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

 

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?