SLOW "Use Asset Database" Play Mode

Hello. Our project has a lot of Addressable assets. Additionally, we have quite a few whole folders marked as Addressable in order to reduce duplicate bundle dependencies. As a result, it is taking over 60 seconds to enter play mode, due to all the processing of addressable groups, when using the "fast" play mode script.

I want to get an understanding of how best to organize our Addressable assets and groups in order to minimize this play mode start time while not making the bundles too inefficient. What specific things attribute to the slowdown of entering play mode via the "Use Asset Database" play mode script? Is it the sheer number of files? The number of groups? Is there a certain folder structure/organization that is particularly slow?

When the Addressable assets are built and we use the "Use Existing Build" play mode script, it is pretty quick to enter play mode. However, since our assets being updated multiple times per day, we can't use this method for day-to-day production.

I haven't yet had a chance to look deeply into the BuildScriptFastMode script. I do plan on doing that soon in order to provide some insight. I just wanted to get a head start on anything obvious I'm missing. Thanks in advance.

 

Are you using v1.8.3? Fast mode is 3 times slower than v1.7.5.

 

We just upgraded to 1.8.3 from 1.7.5 and have found that the "Processing Addressable Group" progress bar that appears when pressing Play in the editor takes about 17 seconds with 1.8.3, instead of about 1-2 seconds with 1.7.5. (this is with the 'play mode script' set to 'use asset database (faster)' and unity 2019.3.7f1)

We have a single Addressable group with all our assets in it, using Assets from Bundles Provider (when built uncompressed its about 2.5GB). We use the "pack seperately" bundle mode and lz4 compression.

 

We recently upgraded from v1.7.5 to v1.8.3 because it was slow with v1.7.5 and wanted to see if v1.8.3 might've improved it. I'll try v1.7.5 again to check if it's maybe just even slower in v1.8.3.

 

But building bundles gets faster....so a very hard choice, but I prefer to stay in 1.8.3....

 

Still excruciatingly slow in 1.9.2 for asset database play mode. It's really hampering iteration time, which is a shame because Addressables are otherwise pretty neat.

We've rolled back to 1.7.5 for development. Any idea when it might be fixed?

 

I can also confirm that the issue still exists in 1.9.2.
If it would help I can report a bug and include my project for the team to help with repro/fixing the issue.

 

Also want to confirm that entering play mode with 1.9.2 is taking a long time. The Processing Addressable Group progress bar takes 20-25 seconds to disappear after pressing the play button.

A little background in case it helps.

I'm porting an existing game from Windows to console, and have my game assets divided up into around 40 Addressable Groups.

Not really sure what best practice is so I've got separate groups for materials, textures, audio, animations, fonts etc. (just so it's easy to remember where everything is and to avoid too much asset duplication) and then separate groups containing level data (mostly prefabs) for the various gameplay zones in the game.

Addressables seems to have achieved the aim of speeding up loading on the target platform, but it's painful to test everything in the editor even when using fast mode.

 

We're finding that it's still very slow on 1.10.0.

In addition, we're finding that it's now very slow when STOPPING play mode as well.

The last version we found to be working reasonably fast is 1.7.5. We held off on upgrading for as long as possible, but we're running into a stuck "Processing Addressable Group" loading bar whenever we enter play mode that doesn't go away until exiting Unity. So we gave in and upgraded to 1.10.0, which fixes the loading bar, but makes playing (and exiting) very slow.

 

Just wanted to check if there's any progress on this. Can confirm it's still an issue on 1.10.0.

It's a shame because I've been using Unity basically since the beginning and one of the defining features was the quick iteration time. I opened up an old project in Unity 5.6 which has a bunch more assets and basically as many scripts, and the time between changing scripts and testing out the changes in play mode is so much faster.

Anyway, having a quick look at the Addressables code and it's building a complete asset catalogue every time you hit play (in "fast" mode), which seems overkill considering how infrequently assets will be added/removed/moved in addressable groups compared to code, scene or prefab changes. I understand that only updating those groups when dependencies change might be hard, but there has to be a better solution surely.

You can temporarily hack around it locally by changing the cached Addressables package script, however it's just a cache so it is overwritten frequently and won't be a great option for non-programmers:
<project>/Library/PackageCache/com.unity.addressables@1.10.0/Editor/Build/DataBuilders/BuildScriptFastMode.cs
Return the result from BuildDataImplementation immediately:

Code (CSharp):

1. protected override TResult BuildDataImplementation<TResult>(AddressablesDataBuilderInput context)
2.         {
3.             TResult result = default(TResult);
4.             return result;
5.  

 

Bumping this for visibility.

@brendanboom What is the downside to that workaround?
Other than editing the cached script, (we have the addressable code in the package folder so we can make edits like this without them being reset anyways)

To answer my own question...It doesnt update the catalog so items removed/added arent registered. Not a great workaround

 

Yeah it's fine in our use-case right now as we're not rearranging the catalogue, and many of our assets are pulled in by direct references in a few "root" assets, but yes that's the downside. It's simple enough to undo the change when the catalogue needs to be updated though.

 

I ended up creating a button we can press to toggle the rebuild catalog. So if we update any groups, we can turn it on quickly and press play once, and then turn it off. Works pretty nicely, already has been saving us loads of time.

 

I can confirm the issue still occurs with 2019.4.1f1 and addressables 1.10.0

 

Big thanks for the Workaround!
I just added a checkbox in my Editor to toggle, whether I want the Database to be updated or not.
Finally i have immediate playmode again .

Code (CSharp):

1. protected override TResult BuildDataImplementation<TResult>(AddressablesDataBuilderInput context)
2. {
3.     TResult result = default(TResult);
4.  
5.     if (EditorPrefs.GetBool("HackDisableAddressableReload"))
6.     {
7.         return result;
8.     }
9.  
10.         // ....
11. }

Edit: Nevermind.... I didn't know that changes to scripts under /PackageCache/ are automatically reverted by Unity, even if you don't update the package.... That makes editing this file not really practicable without moving it out of the /PackageCache/ folder

 

On 2018.4.16, Addressables 1.10.0, play mode in the editor seems to be super slow in another way too. Without a single addressable group defined, loading scenes that are in the editor build settings is very slow. (Loading three asset-heavy scenes in parallel (lights, assets, other logic) jumps from around 12 sec to 53, on a reasonably good PC, even without any of the scenes residing in a bundle). This is so even when using SceneManager.LoadSceneAsync() to load scenes, so when I deliberately try to go around the addressables interface. What could explain this, what am I doing wrong?

 

@Kastenfrosch2 Instead of directly modifying the contents of the Addressables package, you can make a custom subclass of

BuildScriptFastMode

that overrides

BuildDataImplementation()

. You'll need to create an asset from your custom type and add it to your addressable system settings, but that will allow you to customize the build process without needing to directly modify the Addressables package. Here's an example where I've done something similar. Unfortunately this approach of creating custom build scripts doesn't appear to be super well documented, but I've been giving it a try recently and it seems to work well enough for these kinds of simple tweaks to the build process.

 

Oh, also for anyone who's seeing issues with the "Use Asset Database" build script making it slow to enter play mode: Try upgrading to Addressables 1.11.2, it looks like they've tweaked how it works to make loading into play mode faster, hopefully it'll address your concerns without needing to make any custom build scripts!

 

I think it's pretty obvious because there is literally a dropdown for selecting a default build script! And overriding classes, I mean, every programmer should know that

I used this approach to add stuff like IAddressableBuildPreProcessor and better logging of build results. Very easy and very useful.

 

Nice one! Yes, version 1.11.2 fixes the issue for me.

I haven't done extensive testing but modifying code/prefabs doesn't seem to trigger any delay when entering play mode again either. No need to hack the build scripts.

 

OK, it would seem that there is a *huge* performance regression in some version after 1.6.0, performance entering play mode has degraded back to the 1.1.x sort of levels of over a minute on our project.

1.6.0:


1.11.2


In 1.6.0 there was a small delay run when entering play mode (inflated here by deep profiling). In 1.11.2 however there is a humongous delay in InitializeAsync(), which appears to now be generating the addressable asset entries instead and takes about a minute even without deep profiling.

What is going on here, @unity_bill? I can provide a bug report, as this is a very serious regression, but the team already has our project anyway, so it should be pretty easy to check this.

 

This is disturbing. I'm planning to upgrade my project from 1.9 to 1.11 soon and see if loading when entering play mode is slower instead of being faster. That'd be a deal breaker

 

This is just a theory.

In previous versions, there was a huge slowdown when opening the addressables groups window, or adding/removing new items from a group.

I think they moved the function that run at that time, to instead run when you press play. So they just moved the slowdown to a different part of the workflow.

What they should really do is give us a button to manually do it ourselves when we decide to. I edited their package to do just that. And it works great.

 

Please refer to the profiler screenshots I posted from version 1.11.2. This version is unfortunately unusable on our project. 1.6.0 was the first version that performed well without modifications, I did not try versions between that and 1.11.2, and updating to this resulted to the sort of poor performance that we were getting on earlier versions, it's quite a bad regression.

 

1.11.2 has indeed fixed this issue for us. Thanks!

 

Bump, @DavidUnity3d any comments on this? I could submit a bug but generally speaking submitting bugs on this particular system is quite a big task for me, especially when your team already has our project to test on.

 

We have a lot of addressables groups in our project, with code to handle SyncAddressables, and it's still 2min long for me before entering play mode with the new package version (Unity 2019.4.1 + Addressables 1.11.2).

 

Ditto. On 1.6.0 there was a massive improvement, Addressables initialisation was taking 5-6 seconds. On 1.11.2 that time is 55 seconds.

 

I haven't been able to test this thoroughly due to being busy with submission. But, last I briefly checked v1.11.2, it was still very slow on entering play mode as well as exiting play mode. We're on 2018.4.18.

 

I'm now on Addressables 1.12.0 with Unity 2020.1.0.b16 and entering play mode has been fixed for me.

 

As 1.11.2 changed behavor to make play fast, It not load catalog and just search AssetEntry from setting object. But there is a new problem rise up. We set a folder as AssetEntry, and all asset in this folder as SubAsset. Then use AssetReference to point SubAsset to Instantiate at runtime. After upgrade to 1.11.2, it is not work, because AddressableAssetSettingsLocator can not locate key of SubAsset. We have to set build mode to simulate for editor working, And on device is work well.
Any plan to fix it?