Bug Saving a scene cause Application.ExecuteMenuItem to take about 6 minutes to complete

After Upgrading to beta 14 my entire project slowed down. Every action takes minutes or leads to a crash. Downgrading the project version does not help. Why is this happening and how can I fix it ?
This is what the editor loged after a 10 minute wait to save the scene
"
Start importing ProjectSettings/ProjectSettings.asset using Guid(00000000000000004000000000000000) Importer(-1,00000000000000000000000000000000) -> (artifact id: '344b48fc4590ad6a6dcbfc9b57464d8d') in 0.002673 seconds
Refreshing native plugins compatible for Editor in 1.38 ms, found 6 plugins.
Preloading 0 native plugins for Editor in 0.00 ms.
RefreshInfo: StopAssetImportingV2(NoUpdateAssetOptions) scanfilter:
RefreshProfiler: Total: 154.041ms
Start importing Assets/Scenes/Main menu scene.unity using Guid(9b58d4ea5bdcd5048913957f858be1da) Importer(-1,00000000000000000000000000000000) -> (artifact id: '857e5f1e96e4fdd5ae8bc3ad4ece6abd') in 0.000802 seconds
Refreshing native plugins compatible for Editor in 1.18 ms, found 6 plugins.
Preloading 0 native plugins for Editor in 0.00 ms.
RefreshInfo: StopAssetImportingV2(NoUpdateAssetOptions) scanfilter:
RefreshProfiler: Total: 178.427ms"


Edit: Reverting back to beta 8 fixed the issues. Issues were present in beta 12, 13 and 14

 

Submiting the project would be tough since it is rather large. After profiling a bunch I figured out that what takes the most time( about 12 mins) is compiling shaders and more specifically reading from the shader cache.

 

Also see this on Unity 2020.2.1f1. It takes a few minutes to enter play mode.

 

Hey we narrowed down the issue to shader variant caching. Deleting the Library folder fixed it. Also removing a bunch of trird party shaders that were causing the spike in variants.

 

How did you do it? We're having the same issue with waiting for ExecuteMenuItem, but we don't know what causes it. Editor.log doesn't have any long operations logged - only some ms or seconds, but we sometimes wait for 6 minutes.
I thought enabling Editor Deep Profiler would show something, but nope. =(

 

Also having this issue where saving the scene sometimes causes Application.ExecuteMenuItem to take 2+ minutes. It doesn't always happen, but I'm not sure what is causing it to happen when it does. Unity 2020.2.0f1

Edit: Nevermind, its now at 10+ minutes. Guess I'll just kill the application and reopen Unity.

 

Encountering the same issue when Addressable Windows are opened. Seriously annoying.

2020.2.2f1

 

We fixed it by removing Library folder. I guess when you upgrade often, these issues might happen

 

Same problem when I build addressable in android.
It's take my a lot time.

 

On average, it gets stuck once an hour and cannot be solved

 

Same issue... ( Unity 2020.2.6f1 )

and..
ShaderCache.db in the Library folder is very big size.

 

This has seriously affected my development, and I don't think such a devastating error should appear on the lts version

 

A few hours later, the problem came back

 

I'm having this issue as well, gets hung up when creating an android build and saving sometimes. Can take 10 minutes+ to complete these. Really frustrating.

 

I'm encountering this as well. Last two times I've saved my scene, this has run for about 10 minutes.

 

Same issue here. Switching scenes or saving a scene causes 10+ minutes of 'Application.ExecuteMenuItem' popup.

My ShaderCache.db is 19GB in size.

 

up to 12min
in
Unity 2020.3.2f1 and 2020.3.3f1



Is there any way to find out why?

Adressable and Package Manager Windows are closed.

 

Read this thread from here: https://forum.unity.com/threads/lots-of-busy-hold-on-etc.833644/page-6#post-6906902
You will need to use some sort of profiler. If you find that Unity is a culprit, please, submit a bug report with hard data so they can fix it.

 

So wait is the ShaderCache.db supposed to grow to that size? I don't think that was intended behavior right?

And also, if it does grow. I guess this thread is hinting that for now, best practices for quicker editor load times, is to delete that file prior to opening up that project every time..

This is kinda hilarious. Reminds me of my Dad's old TV, where he'd used to have to give it a little wack, every time the the connection was poor or dropped, and then it works again.

 

Same Problem here - but only Windows seems to be affected. My mac is having no issues at all with the same project.

 

I'm also having such issue with Application.ExecuteMenuItem and Application.EnterPlayMode processes duration. It takes around 15-25 seconds and happens very often when saving the scenes after returning from play mode. It's a big time waste.

Restarting the editor helps but the duration slowly increases as long as you working on the project.

Addressables or URP packages might be the cause but not sure. Does anyone have something on this?

I'm on 2021.1.7.

Editor Profiler:

 

I also use URP, and I've a hunch that URP had something to do with it, because my other projects just using standard render pipeline never had this loading issue.

 

This is affecting my whole team. Using URP.

 

Same here, using Unity 2020.3.12f1 and URP 10.5.0

It's killing our productivity, please do something

 

Having the same issue in 2020.2.2f1 HDRP. It takes 20 minutes to an hour

 

Same issues on latest LTS or 2021.1.15f1 etc, it will just get stuck sometimes causing me to loose work because Unity locks up and forces me to close it from the task manager.. Really needs resolving asap. It is really not reliable to work like this (URP) and I am pretty close to just giving it up and going to Unreal.

 

Version: 2020.3.14f1, URP: 10.5.0

I had the same problem, the waiting was around 6-10 minutes.

Since I upgraded the project several times, my library folder was relatively huge (27 GB).

I deleted the library folder, and now it works just fine from 3-4 days (10-12 working hours per day).

If your situation is like mine, try to delete the library folder (in your project folder). But make sure you backup your project.

Although as most people say, you can safely delete the library folder, I saw several people had some problems after deleting the folder.

Hope this helps.

 

Sadly it even happens on pretty new projects, been like this for ages now (even the LTS versions) and not just me, many co-workers have the same issue.

 

I generally noticed the versions after 2019.3 starts to slow down, especially after importing asset import pipeline v2. Not sure if it has anything to do with the current situation though.

The previous version (like 2019.2) was much faster, even after code compiling.

 

2020.3.8f1 URP Android Builds, same issue
Deleting lib folder helps temp but eats lot of time..

 

2020.3.9f1 is regularly taking 3-5 minutes to save a scene. Is there anyone from Unity that can comment on this? I'm debugging/tweaking a VR project and by the time I make a code change, save and get in to test - it can take 10 minutes. Only making five or six changes per hour is just impossibly slow. I'd have thought this was a critical issue?

 

This also happens to us all of the time and started probably with Unity 2020 and now Unity 2021. It is amazing something that is taking so much productive time from so many developers is not a higher priority. I love Unity, but hate having to just sit here waiting all the time and knowing my entire team of developers I having the same issues. Every save of scene takes a good time before anything else can be done.

 

Same issue on Unity 2020.2 and now 2020.3.

VR project using OpenXR and URP.

We're now used to delete library every couple of weeks, because it's only a temp fix as said in this thread.
That's really killing our productivity

 

Same issue, multiple times a day. On a good day maybe 3-4 times a day, on a bad day every 10 minutes. I have to kill Unity and restart it, which doesn't take more than a minute, but is extremely disrupting to workflow.

I can't pinpoint or reproduce it, sadly. Deleting and rebuilding the Library folder didn't help.

 

2020.3.15f2, URP: 10.5.0.
Same issue here. I noticed that whenever this happens I have this unity process consuming cpu before and after the hang:


But profiling in the editor shows that the editor itself is not consuming cpu.
I waited for the process to finish and checked the log but not a line have been added.
What is this process doing exactly ?

 

Happening to me too. Switched to URP yesterday. Didn't have this issue earlier. Using 2020.3.17f1

 

2021.1.18
Unity was hanged at least 10 times a day.
I don't even know what the cause is.

 

Unity2020.3.11f1　HDRP

A similar phenomenon is occurring

 

Absolutely the same problem, I just make a click and the loading appears for 20 minutes! I have a serious project now and this problem is very annoying and slows down the development process. Please fix it.

 

Same problem here. WTF, Unity, are you still out there?

 

I've also been getting the ExecuteMenuItem slowdown during the saving of my scenes and it really kills my productivity. I'm on 2020.3.11f1 and this didn't happen on the same project under a previous version of Unity (2019.4 LTS). I tried deleting my shadercache file and it didn't help. Seems like every time I update Unity it fixes some of the bugs I get, but I always find 5 new ones in their place.

I could try running the Profiler to narrow down the exact call that's eating up all this time but I don't think it's going to give any information that hasn't been shared in this thread already. I could try updating unity to a newer LTS version but at this point I'm afraid about what else could break. If it was confirmed fixed in a newer version I'd have no qualms moving my project to it but as of yet I'm not sure if there's been any news on the issue and I don't even know how to begin debugging it. I'd also be willing to submit my project via a secure upload site if a Unity dev needs a specific test case; could be project-dependent. I just really hope there's a way to eliminate the problem.

 

Found a solution that caused most of my problems:
For some reason the visual studio startup project got set to an Odin Assembly. When I switched it back to my main assembly it seemed to clear up all save hangs. I don't know if it is a permanent fix since the problem is intermittent, but I've noticed a good improvement.

 

FYI I'll bet my left nut this is something to do with Odin based on the previous posters comment and the fact that I just started encountering this within 10 minutes of installing Odin for the first time ever.

My ShaderCache is only like 3-4MB - so I don't think it's related to that.

Although to note I'm using Rider, not VS, so I don't think it's a VS specific issue, as much as it might be something to do with the refresh your editor triggers in the Unity editor once you save a code-change.

Going to try removing Odin and see if it goes away as a kind of smoke test.

 

Checking back in - have removed Odin and have been working for around 3hrs with no lock-ups. I was getting a lockup every 10-15 minutes before when Odin was installed.

 

I found a solution, even if it is annoying:

"For this specific case of "Hold on..." you should be able to work around it by simply killing the import worker process from the task manager. The import workers are also called "Unity", so to distinguish them from the Editor you can add the command line column in the windows task manager and kill the Unity processes that are import workers (they have -batch cmdline flag and worker name cmdline options set)."

Killing this process did indeed unfreeze unity and remove the popup.

After that, save again and it should go through.

 

Thanks for the command line column tip @Armend

 

2020.3 HDRP same issue. saving a scene takes about 1 minute.

 

Same issue here y'all, 2020.3.15f2 (LTS). Doing any general action is a dice roll on if I'll be waiting 5-10 minutes while Unity shows me a loading bar. Will definitely give Armend's tip a try.

 

Same issue, there is any fix? I couldn't apply the Armend's fix