Any update regarding "Increased script assembly reload time"?

@xoofx If that's the case, can u provide toggle for users to disable features that's not required for their specific project?

 

@xoofx I appreciate your personal advocacy and the effort of the multiple teams working on this @ Unity. Please know this.

Is this an aspirational goal of 1s to 2s for a bare bones project or for a (A)AA project with 20,000+ assets and 5,000+ .CS files? Is the goal tied to high-end developer workstations with NVME SSDs or mid-level hardware?

Quite understandable but then Unity caused this. Unity's priorities need to reflect that commercial customers don't care about new features if the overall product is unusable at scale. Harsh but true.

 

@xoofx Thanks for letting us know. Do you know if these fixes will be backported to the 2021 cycle, or will we have to wait for the 2022 versions?

 

I mean Unity is clearly showing their priorities through their actions, their product and the services they provide.

It's not like we got here because someone clicked the wrong button, we got here because the combined vector of decisions (with whatever weights you want) done at Unity over the last 5 years, led to Unity becoming a frustratingly slow and unpleasant editor to use.

And that can't be undone with 1-2 years of them saying they changed priorities.

 

Not sure if the Asmdef debugging scripts have been mentioned in this thread before, but I was using UnityAssemblyDefinitionDebugger.cs for a while to try to understand where the assembly reload latency was originating. I just found this forked and updated version: Unity-Assembly-Debugger which I think presents a slightly clearer picture of which assembly was reloaded and how long it took.

It might be worthwhile to collectively give the Unity team some numbers from either of these debugging scripts as they should highlight where the latencies are coming from when reloading assemblies.

In my experience the bulk of the time spent reloading assemblies after even the most minor script change was coming from Unity assemblies, and not my project code. From there I was able to use the Editor Iteration Profiler to see where Unity was spending so much time during assembly reload; for example, having the Package Manager window open was adding ~5-10s (sometimes more) of latency during an assembly reload(!). Closing it prevented the Package Manager code from being reloaded after I updated my own project code.

 

Sorry but its 100% a Unity issue, it happens despite machine across multiple people in the dev team across Mac and PC. LTS specifically is the problem.

 

I don’t understand why the editor appdomain reloads these packaged Unity assemblies. Isn’t the point of using a custom appdomain the ability to arbitrarily add/remove assemblies at runtime? e.g, a plug-in system. When should a Unity specific assembly get recompiled or reloaded into the editor’s appdomain if it is unchanged? How does this compare to what is happening today, re: iteration performance?

 

Not exactly related, but since this is also about domain reload delay :

I am not sure if it is just me, but I found "Enter Play Mode Options" pretty much useless, because when you are developing a game, entering play mode can be followed by any kinds of activities which involves having to reload the domain most of the time, and even if it need not to, it is so much hassle to go into the project settings every time and change the option before entering the play mode. This may be another case of "there is feature but not very practical to use" of Unity but a simple button or option next to the play button would have been much better alternatives.

There are many features in Unity that "seems" to be useful, but not really until when you actually try and use them everyday for the game development. I post these almost everyday but well... the change and updates are slow and painful. (if it ever happens)

 

Enter play mode options is the best thing Unity has made for a long while. If you understand what it does, and how to write your code in order to take advantage of it, there's no downsides left, while you get a massive boost in the time it takes to enter play mode.

It caused Unity 2020 to be the best version for iteration times we've ever used, and we've been with Unity since Unity 3.

 

Nope, I definitely will if you recommend that one.

 

@xoofx
Is it an accurate observation that the 2021.1.x editor is recompiling and/or reloading Unity packages when I make a change in one of my project scripts? If reloading of Unity packages is occurring, why is this the case? Unity packages would have no dependency on my code and .NET app domains allow for piecewise load and unload of assemblies.

 

@Tautvydas-Zilys, I could be wrong, but the behavior that @stonstad described where changing and then saving project code caused Unity specific assemblies to reload is what I was seeing with 2021.1.x. I tracked this behavior down using the EIP, UnityAssemblyDefinitionDebugger.cs, and Editor logging (search string "Domain Reload Profiling"). For example, having the Package Manager window opened was adding 5-10s of latency after saving project code and waiting for Unity to reload its assemblies. In the case of the Package Manager I could see that Unity was reloading the Package Manager code whenever I made a change to my project code (and to be clear, this was not the only portion of Unity that was reloading when I made a change, just one of the more obvious and egregious ones).

Is it possible that portions of the Unity codebase inadvertently could be reloaded when Unity detects a change to an asset such as a csharp script?

 

I imagine that the editor loads and unloads assemblies within a single app-domain. In this scenario only the user (project) code’s assembly is reloaded when a script change occurs. The unity assemblies would remain loaded until changed, right?

 

Yes, that is what I am observing and asking about. What is the expected behavior? We know something is amiss here because even an empty project has an extended iteration time, and in that scenario there is practically no user code to load into the appdomain.

 

That is what happens with Project Settings. It adds ~500ms if I left it open.

 

There is considerable complexity with appdomains and compilation that I don’t understand. Thank you for sharing more detail.

 

I'm seeing assembly reload taking really long time

 

Just to add a bit more detail.
It is genuinely puzzling why a single line change(not even code change, just empty space) would induce this vomit of changes that's taking 4-5 secs minimum.

 

This capture is taken after closing unncessary settings and profiler windows, still the same. A single line change in user code triggers an assembly reload of 5800ms. The report is also attached as an html file for anyone interested to explore.

 

I can literally create a new URP project and edit nothing except add some scripts and eventually it will happen. Everything else default. It happened today with some sample code I was writing - one script with a simple function that sends a web request. No extra packages or anything fancy.

 

A minute with "RestoreManagedReferences

 

The reason is that you're triggering the same action, doesn't matter if it's a space or actual code changes.
It's going over everything again, resetting state and code.
You can disable it with the 'enter play mode options'.
it'll be really fast, almost instant, because it's not doing that anymore every time you save a script change.

but because it's off, your own code has to reset itself, and any code your project uses. Otherwise it might cause some issue.

 

I thought the enter play mode options doesn't decrease assembly reload time, only the enter play mode time