Bug (Case 1355534) Addressables 1.18.15 Inspector performance regression

After updating from Addressables 1.18.13 to Addressables 1.18.15 the Inspector performance in my "real" project has significantly worsened.

The Inspector takes about 500ms to 1sec to update (without deep profile), so you can't really scroll or change values anymore. Downgrading Addressables to 1.18.13 got rid of the issue.

I'm unable to reproduce this in an empty project. Please ask the Addressables team to look into the issue nonetheless, @TreyK-47. It's probably related to the number of assets and AssetGroups in the project. It reproduces 100% in my actual project.

I've attached a "Deep Profile" of my real project where this issue occurs, as well as screenshots from the profiler to the bug-report (Case 1355534).




Reproduce

1. Open a mid-sized project, my project contains 20000 files, 1200 folders and 130 AssetGroups (or open project from Case 1360240)
   
2. Select "Main Camera" in the Inspector and scroll or change values

Actual
The Unity Editor is so slow that working with the Inspector is no longer possible. There is a huge lag when changing values.

Expected
The amount of assets, folders and AssetGroups does not affect the Editor performance.

Notes

1. Closing all Addressables windows (Groups, Hosting, Profiles, etc) did not cause the performance issue to go away.
2. Restarting Unity did not cause the performance issue to go away.

Other users seem to be affected by this problem too:

1. https://forum.unity.com/threads/editor-performance-issue-in-version-1-18-15.1155740/

 

The QA replied that they're unable to reproduce this problem and ask for a project where it reproduces. Does anyone of you have such project that you can submit with a bug-report?

Sending the project to Unity is difficult for me, because I don't own the rights. I believe creating an isolated test-case for this problem is difficult too and will take a long time.

If you have a project where this issue occurs and you're able to submit your project to Unity Technologies for them to take a look at the problem, that would be just lovely.

Please leave a message here with the bug-report Case number, so I can update my original report and let the QA know where they can find a project to reproduce this problem.

 

Also having this issue, and cannot submit a project.
It occurs for me when I inspect a prefab that is implicitly included via a folder. Because that folder contains ~14,000 files (including .meta files), and this code path doesn't seem to be setting the m_PrecomputedTree it's repeatedly enumerating all these files.

 

Scratch that, it was an extremely easy bug to replicate in a new project. I just ran the classic:
Grouped a bunch of the folders together, made that folder addressable, and selected one of the files.

Case 1360240

Issue tracker link has been issued

 

Awesome, thank you!

 

Is the problem solved for you? At 1.19.6, I still have low inspector performance.

 

1.19.6 fixed the issue for me, but perhaps it's also somewhat project specific.

 

Based on your description, there are 10 times more files in my project, perhaps this is the reason. I haven't noticed any improvements since upgrading to 1.19.6. Also, in my case, a visible decrease in performance occurs if open the inspector where there is at least one material. The more materials, the lower the performance.

I attach a screenshot of the profiler on 1.19.6, where the inspector with about 10 materials is open.

 

Hi.
I was frustrated by this bug, so I executed following script.

Code (CSharp):

1.  
2. [MenuItem( "Temp/Kill Addressable Header" )]
3. public static void KillAddressableHeader()
4. {
5.     var asm = Assembly.Load( "Unity.Addressables.Editor" );
6.     var internalClass =  asm.GetType( "UnityEditor.AddressableAssets.GUI.AddressableAssetInspectorGUI" );
7.     var method = internalClass.GetMethod( "OnPostHeaderGUI", BindingFlags.Static | BindingFlags.NonPublic );
8.     var headerEvent = typeof( Editor ).GetEvent( "finishedDefaultHeaderGUI", BindingFlags.Static | BindingFlags.Public );
9.  
10.     var d = Delegate.CreateDelegate( typeof(Action<Editor>) , method, true );
11.     headerEvent.RemoveEventHandler( null, d );
12. }
13.  

As you know, this is "first aid".
I hope Unity fix this issue.

(My unity version is 2020.3.22 and Addressables is 1.19.14.)

 

Same issue here, using 2020.3.25f1, verified Addressables 1.18.19.

Updating to 1.19.6 fixed the issue for me as suggested by @Peter77

In our case, we have a GameDatabase folder which contains a 'lot' of scriptable objects for each entry in the database. We mark only the folder as Addressable and the child assets are automatically included. There is only 200, so its not really 'a lot'.

The editor is unworkably slow when selecting any asset that appears in that group.

Deep profiling shows this:


Might as well vent while I am here: This seems like another issue that would have been spotted easily if there was a team at Unity using their own products on any real game. Its not good enough to run your packages through automated test suites against example/sample projects without ever actually using them in person.

 

I have the same issue, even looked at the addressable code.
I have tons of addressable objects in my project (scenes, about 900 prefabs, that expand to much more addressables because of textures, materials and such)

The problem is unity is trying to determine if the object you clicked is addressable, by looping over all the addressable objects, just to show a checkmark on the inspector's header, total waste of time for me.

hacked it with similar method that ss_naomichi posted, by removeding the action of addressables from OnPostHeaderGUI

 

Unity's QA should create a script to create lots of fake prefabs, and mark them as addressables, and I'm sure the problem will reproduce

 

I received a response to the bug report back on October 28th, saying that they were able to reproduce the issue with the help of my project, but nothing has been fixed so far...

 

Hi.

I confirmed this issue had been fixed on Addressables 1.19.17.
However, I can not find any descriptions about this issue in changelog.