Editor Progress Bar stalls (request for bug reports)

[richardkettlewell]

Hi!

We are interested in collecting reproduction projects for any time the Editor unexpectedly stalls. On Windows, this shows the blocking Progress Bar Dialog.

To gather this data automatically, we are adding analytics information to report the causes for all stalls. However, until that is ready, if you would like us to investigate/fix any specific scenarios, this is a call for bug reports!

There are a few “expected” stalls, such as making a player build, importing assets, entering playmode, which we don’t want to focus on here. There are ongoing efforts to improve all those kinds of things separately. I want to focus on other cases in this thread, where you feel that Unity shouldn’t be making you wait.

If you’d like to send us a bug report, and are able to submit a repro project to go with it, we would love to take a look at them.
Put a link to this forum thread in the report, so QA know why you are submitting it, and then reply below with the case number, so we can keep track of these reports.

Also, the Windows Editor has a Diagnostic Switch in Unity 2021.2, which writes out information about any stalls to Logs/stalls.log in the project folder. To enable that, go to Editor/Preferences/Diagnostic Switches, and enable Editor/WriteOutStallStackTraces.

In the diagnostics menu, you will find three different settings.

1. WriteOutStallStackTraces: Check this one to write out profiling data about stalls in general to a logfile (you can find that in your project folder in Logs/stalls.log)
2. WriteOutStallStackTracesIntervalSeconds: This controls how long we wait between capturing profiling data. The default value is once per second. This works fine for long stalls (e.g. you see the progress bar for many minutes). You can reduce this to lower values (down to 0.1 or 0.01 in extreme cases) for shorter stalls like 10s or 15s.
3. WriteOutStallStackTracesThresholdSeconds: This controls how long the editor needs to be stalling before we start to write out any data at all. The default value is 10s. To capture shorter stalls, you will have to reduce this value.

Enabling this diagnostic switch can impact the editor performance and stability, so we recommend turning it off again when you have finished using it.

You can copy a particular stall out of the log file into its own file, and then open it in https://www.speedscope.app/ to view it, but, more importantly for us, if you attach it to the bug report, it will give us more information.
And finally, if it’s not possible to send a repro project, please do still send the stall report as this provides us with valuable data.

Thanks!

[OtakuD]

So I’ve been trying to find the source of the slowdown as best I can and found this post which allows to somewhat debug 2021.1 instead of the beta via command line.

In the logs I find the following items taking the most time each time I change a file and recompile, any info as what they are and what could cause this? I’ve seen values from 6k-37kms on compile even though I’ve restarted Unity etc. so importing should be done?

ImportAndPostprocessOutOfDateAssets: 37871.933ms (37825.510ms without children)

RefreshProfiler: Total: 6900.726ms
    InvokeBeforeRefreshCallbacks: 0.755ms
    ApplyChangesToAssetFolders: 0.067ms
    Scan: 5.730ms
    OnSourceAssetsModified: 0.000ms
    InitializeImportedAssetsSnapshot: 20.578ms
    GetAllGuidsForCategorization: 1.733ms
    CategorizeAssets: 181.699ms
    ImportAndPostprocessOutOfDateAssets: 6659.925ms (6610.990ms without children)
        PostProcessAllAssets: 0.002ms
        EnsureUptoDateAssetsAreRegisteredWithGuidPM: 4.299ms
        InitializingProgressBar: 0.000ms
        PostProcessAllAssetNotificationsAddChangedAssets: 1.749ms
        OnDemandSchedulerStart: 1.030ms
        RestoreLoadedAssetsState: 22.890ms
    UpdateImportedAssetsSnapshot: 18.964ms
    ReloadSourceAssets: 16.511ms
    UnloadImportedAssets: 1.452ms
    Hotreload: 2.891ms
    FixTempGuids: 0.006ms
    GatherAllCurrentPrimaryArtifactRevisions: 0.748ms
    UnloadStreamsBegin: 0.118ms
    LoadedImportedAssetsSnapshotReleaseGCHandles: 1.464ms
    GetLoadedSourceAssetsSnapshot: 27.663ms
    PersistCurrentRevisions: 0.760ms
    UnloadStreamsEnd: 0.096ms
    GenerateScriptTypeHashes: 11.414ms
    Untracked: -21.468ms
[MODES] ModeService[default].RefreshMenus
[MODES] ModeService[default].UpdateModeMenus

RefreshProfiler: Total: 31210.297ms
    InvokeBeforeRefreshCallbacks: 0.745ms
    ApplyChangesToAssetFolders: 0.068ms
    Scan: 5.545ms
    OnSourceAssetsModified: 0.001ms
    InitializeImportedAssetsSnapshot: 20.777ms
    GetAllGuidsForCategorization: 2.057ms
    CategorizeAssets: 197.224ms
    ImportAndPostprocessOutOfDateAssets: 30953.849ms (30902.882ms without children)
        PostProcessAllAssets: 0.002ms
        EnsureUptoDateAssetsAreRegisteredWithGuidPM: 4.338ms
        InitializingProgressBar: 0.001ms
        PostProcessAllAssetNotificationsAddChangedAssets: 1.790ms
        OnDemandSchedulerStart: 1.286ms
        RestoreLoadedAssetsState: 23.316ms
    UpdateImportedAssetsSnapshot: 20.234ms
    ReloadSourceAssets: 18.541ms
    UnloadImportedAssets: 1.511ms
    Hotreload: 2.764ms
    FixTempGuids: 0.008ms
    GatherAllCurrentPrimaryArtifactRevisions: 0.702ms
    UnloadStreamsBegin: 0.097ms
    LoadedImportedAssetsSnapshotReleaseGCHandles: 1.478ms
    GetLoadedSourceAssetsSnapshot: 28.292ms
    PersistCurrentRevisions: 0.784ms
    UnloadStreamsEnd: 0.089ms
    GenerateScriptTypeHashes: 12.164ms
    Untracked: -24.235ms
[MODES] ModeService[default].RefreshMenus
[MODES] ModeService[default].UpdateModeMenus

[altepTest]

I have had/have this issue of ImportAndPostprocessOutOfDateAssets as posted by me in this thread.

What is "ImportAndPostprocessOutOfDateAssets" and why it takes so long each time I open the project?

Every time I open the project it takes 10 minutes to load, looking at the log files this line appears to take the most time. What is ImportAndPostprocessOutOfDateAssets and why it needs to do this every time I load the project? What are these out of date assets and why they go out of date every time I close the project for more than a few hours. Basically, new day, open project, takes 10 minutes. Close project/unity (keep hub open) wait a couple of minutes, open unity, less than a minute pro…

That same project after showing that issue of low loading time, later started to have the UI loading bar block.

This may be related with this thread issue as watching the logs after the UI hangs up with the loading bar the same ImportAndPostprocessOutOfDateAssets is listed as taking a long time to complete.

My guess is that unity thinks the files had been changed and will import them again which blocks the editor till the process is complete. More files you have worse it gets. More third party assets you have with a lot of textures, models, complex animations, longer it takes.

[Baste]

@richardkettlewell

Also, the Windows Editor has a Diagnostic Switch in Unity 2021.2, which writes out information about any stalls to Logs/stalls.log in the project folder. To enable that, go to Editor/Preferences/Diagnostic Switches, and enable Editor/WriteOutStallStackTraces.

Any chance of backporting that to 2020 LTS? I’m seeing some intermittent stalls when opening Quick Search, but we’re on 2020, so I don’t have access to the switch.

[KospY]

Yeah would be great to have this backported to 2020 LTS, I encounter this issue every day so that will be easy to report, but we are not going to update our project to 2021 before a while, and it would not be a good test as we may not have the same issue on 2021.

[nasos_333]

The biggest stall i have seen so far is related to shader compilation, when i enable the async parallel compilation i see an exponential increase in compile time, eg. 2 minutes versus 3-4 secs.

This is obviously some extremely serious bug in there, other users not see the issue though, so cant tell exactly when and how it happens.

For my case was like a revelation when turned off the feature and from waiting minutes for a single tiny change, was reduced to seconds.

I noticed this option to turn it off is not available in later Unity version and wondering if the shader baking i saw today in my HDRP project could be done in less than the 2 hours it took if this option was turned off.

Please add back the ability to turn Off the async shader compilation in all Unity versions, since it appears to be extremely buggy in some cases.

[JesseSTG_1]

Case number is 1355893, on Unity 2021.1.16 on Windows 10. I’m seeing this stall damn near every time I open something up in the inspector, especially (but not exclusively!) when I use Odin attributes.

Whatever’s happening, it’s happening in InspectorWindow.Repaint.

This is incredibly frustrating; it’s preventing me from getting any work done. It’s almost a blocker. It’s taking me over a minute just to drag some assets from the Project view into an array.

EDIT: Oh thank God, they reproduced it. I’m not crazy!

[s_schoener]

@JesseSTG_1 - this is exactly the kind of report that we are looking for. I was able to reproduce the stall: The main culprit here is the addressables package. I don’t have any ETA on a fix yet but I’ve alerted the team. Thanks again, and sorry for the inconvenience - I know it sucks when Unity isn’t responsive

[altepTest]

hope this is the time! maybe finally it will be fixed

[JesseSTG_1]

@s_schoener

@JesseSTG_1 - this is exactly the kind of report that we are looking for. I was able to reproduce the stall: The main culprit here is the addressables package. I don’t have any ETA on a fix yet but I’ve alerted the team. Thanks again, and sorry for the inconvenience - I know it sucks when Unity isn’t responsive

Really? Huh. Of all things. I’m actually curious, can you elaborate? (Feel free to go into as much detail as you’d like.)

Thank you very much!

[Kurt-Dekker]

@s_schoener

I know it sucks when Unity isn’t responsive

It’s actually a bit worse than that because when you are in the flow it completely disrupts you, knocking productivity to the ground. It’s absolutely miserable how slow 2021 has become, and that is even with TINY projects, projects with a total of 20 to 30 files!!

I am sure your teams will sort it out but just know that virtually every developer I know, if this was their first impression of using Unity, would absolutely never consider using it again. This lagginess has got to be seriously impacting your user base and I’m not sure your analytics are showing it.

[djdanlib]

I have a theory that when I have 2 monitors on, save a project, quit, and come back to it later with only 1 monitor, the editor stalls forever when starting up and has to be killed, and for some reason it starts fine the next time after that. It doesn’t seem to happen if I have both on prior to starting the editor, or if I save it with only 1 on. Not sure if it’s total coincidence though, I don’t have much time to test this.

[John_Leorid]

Here is a very easy to reproduce one:

using UnityEngine;

public class LagTest : MonoBehaviour
{
    public Vector3 a1, a2, a3, a4, a5, a6, a7, a8, a9, a10;
}

Create this script in an empty project.
Create any Object (Empty, Cube, whatevery you like) in a scene.
Add the script 20 Times to the Object in the scene.

Now change a value in any of the 20 scripts or move the object around.

Result:

If this is a player character, which is constantly moving, you can’t play the game while the inspector is open, you have to close it or hide it in order to be able to play at a stable framerate.

Possible Solution: Give us the option to fully switch to UI Elements in the Editor, render everything with UI Elements. I’ve seen it in EditorDeveloperMode.Internal, it is just a bool to set, might not fully work, but I am willing to take the risk.

(Fun Fact, the Profiler is also rendering using IMGUI, which probably makes it about 5000% slower than it would be with UI Elements)

[altepTest]

but the above is not related with the bug where unity shows a loading bar for 10+ minutes or more.

[s_schoener]

@altepTest

hope this is the time! maybe finally it will be fixed

There is no “it will be fixed”, unfortunately. As stated many times before, there is no “single thing” that makes Unity slow. The progress bar pops up whenever the main thread is blocked for longer than a certain time (usually 10s). This can be caused by practically anything, including my code, your code, the code in one of the many asset store packages you use, any Unity package, any Unity core code, the possibilities are literally endless. The only thing that makes it better is to (a) fix all instances as they come up, (b) add more testing on scale, and (c) make it more discoverable when user code causes this problem, which are all things that we are actively doing. Given the sheer size of Unity and the number of different combinations of packages and the fact that user code can introduce all of these stalls as well, this is a truly herculean task and it will never be done. Though good bug reports like the one from @JesseSTG_1 accelerate progress a lot

@Kurt-Dekker

It’s actually a bit worse than that because when you are in the flow it completely disrupts you, knocking productivity to the ground. It’s absolutely miserable how slow 2021 has become, and that is even with TINY projects, projects with a total of 20 to 30 files!!

As someone who uses Unity every day in their work and then every day in their private life to build their own games, believe me: I know how slow things are. My job right now is literally to look at all of the cases that are slow, so I see it all I know it doesn’t help you right now, but you have my sincere empathy for how much it sucks when the editor is slow or stalls

@John_Leorid

If this is a player character, which is constantly moving, you can’t play the game while the inspector is open, you have to close it or hide it in order to be able to play at a stable framerate.

Fun fact: I ran into that same issue on my home project. It’s actually been improved significantly in 2021.2.0a14 (and yours truly recently added a performance test to make sure nobody is ever going to make that slow again). Also, just switching everything to UI Toolkit is probably going to introduce a whole truckload of new problems, which is presumably why the responsible team is holding off… and I’m pretty sure they’d like nothing more than to get rid of ImGUI

@JesseSTG_1

Really? Huh. Of all things. I’m actually curious, can you elaborate? (Feel free to go into as much detail as you’d like.)

Thank you very much!

You’re welcome! So I haven’t looked into all of the details because I looked into it afterhours on a Friday night, but the short summary is this: The addressables package draws a custom header in the inspector. That header is very slow to draw in your project because it is enumerating some assets for UI purposes. I’ll take another look on Monday and see if there is any easy workaround for you locally. Thanks again for your report, that’s the good stuff we’re looking for.

[richardkettlewell]

@OtakuD

any info as what they are and what could cause this?

Hi,

Thanks for the feedback!

I’ve passed this log along to the relevant team who are going to look at whether we can add more detail as to which part of that step is taking the time.

In the meantime, if you are able to submit a bug report, I could look at your specific situation.

[april_4_short]

@s_schoener

The progress bar pops up whenever the main thread is blocked for longer than a certain time (usually 10s). This can be caused by practically anything, including my code, your code, the code in one of the many asset store packages you use, any Unity package, any Unity core code, the possibilities are literally endless.

If you can monitor stalls in this manner, and show a popup at this time, couldn’t you add a button to the pop up that says “wanna let us do a trace of what’s blocking the thread?” and then do that if the user says "YES!’ and send it to somewhere inside Unity that’s relevant?

This problem is legion, so time to start thinking about how to get ALL the data you can about what’s causing it?

[s_schoener]

@april_4_short : I like the idea. I’ll see what I can do. We went through similar ideas but the stack tracing code was a bit flaky before I introduced that diagnostic flag (see OP), so I think you are right that this is an avenue worth exploring again. Thanks!

[JesseSTG_1]

@s_schoener

There is no “it will be fixed”, unfortunately. As stated many times before, there is no “single thing” that makes Unity slow. The progress bar pops up whenever the main thread is blocked for longer than a certain time (usually 10s). This can be caused by practically anything, including my code, your code, the code in one of the many asset store packages you use, any Unity package, any Unity core code, the possibilities are literally endless. The only thing that makes it better is to (a) fix all instances as they come up, (b) add more testing on scale, and (c) make it more discoverable when user code causes this problem, which are all things that we are actively doing. Given the sheer size of Unity and the number of different combinations of packages and the fact that user code can introduce all of these stalls as well, this is a truly herculean task and it will never be done. Though good bug reports like the one from @JesseSTG_1 accelerate progress a lot

As someone who uses Unity every day in their work and then every day in their private life to build their own games, believe me: I know how slow things are. My job right now is literally to look at all of the cases that are slow, so I see it all I know it doesn’t help you right now, but you have my sincere empathy for how much it sucks when the editor is slow or stalls

Fun fact: I ran into that same issue on my home project. It’s actually been improved significantly in 2021.2.0a14 (and yours truly recently added a performance test to make sure nobody is ever going to make that slow again). Also, just switching everything to UI Toolkit is probably going to introduce a whole truckload of new problems, which is presumably why the responsible team is holding off… and I’m pretty sure they’d like nothing more than to get rid of ImGUI

You’re welcome! So I haven’t looked into all of the details because I looked into it afterhours on a Friday night, but the short summary is this: The addressables package draws a custom header in the inspector. That header is very slow to draw in your project because it is enumerating some assets for UI purposes. I’ll take another look on Monday and see if there is any easy workaround for you locally. Thanks again for your report, that’s the good stuff we’re looking for.

The public ticket doesn’t reproduce the issue with Addressables 1.18.11, so I downgraded to that for a while. Will it work? I dunno; I have several things to do IRL before I can try it out.

[courtrick]

Currently I have been waiting for over 10 minutes at the time of writing with a progress bar that simply says EditorApplication.playModeStateChanged. To say that this is annoying is an understatement that frankly makes me wonder if something is wrong on my pc. I’m looking forward to at least having a way to improve this in the future.