Lots of busy... Hold on.... etc?

just now I clicked "file"

 

Probably time to bring out the profiler and profile what is happening. And if the problem is in unity itself and it is not a rouge asset or editor window modification, file a bug report with the profiler results.

 

The problem with the busy popup is that it doesn't show any useful information about why Unity is busy. Just showing the entry point, like Application.ExecuteMenuItem, it useless.

 

@Aras @MartinTilo
Empty HDRP 11 project in 21.1b6 (21.1b8 was even longer script with enter play mode and script compilation)
after quiting play mode, editor viewport does not respond

Why is asset database reloading but there's almost empty project? Why are .Repaints happening?

 

@UnityMaru What about when you update a project from a version below, and then it starts doing this without any actual changes in the project?

This is how it has happened for me, suddenly with the new 2020 versions i am getting waits that did not exist before, and, they are happening with increasing regularity. For some reason, something *inside unity* has changed, not inside my project for which the only code changes have been within one script.

Atm the entire process of using unity at all has become horribly painful, waiting whilst unity wastes time with the simplest request - to open a menu, or to select the inspector... pretty much anything, and if you want actual proof that it is nothing to do with the code in these projects, what about the fact my project doesnt include any shaders written by me, or, any objects which possess their own shaders, and yet one of the stupid long waits comes from when you select the shader dropdown for a material.

I would be happy to send my entire project if it would help to diagnose this problem, as at the moment i am spending 75% of my time in unity *waiting for unnecesarily slow actions to complete*.

I just clicked save, for example, as i was about to do a build, and the save took around 7 mins, in spite of there not actually being any changes made... If i collated the time and access speeds my os reported during this period it could have easily copied and duplicated my project several times over, and, it even manages to make the os report impossible disk access times as well, it reported around 2gb per second access speed on a fairly standard hard drive which clearly cannot perform at that speed...


There is something fundamentally wrong inside the program, and, i have a sneeking suspicion that it is deeply embedded into the systems being used to show these new progress bars. When it is being slow the progress bar says things like "repaint" or something, always suggesting that the slowdown is inside the actual gui component behaviours reading the information, and, that it isnt actually doing anything useful.

On occasion the delay says things like "importing" and so on, but those tend to pass quickly, and then it spends 97% of the time at a point like Repaint, or, refresh... things which should be and always used to be very quick.

 

Just to prove the point im gonna see if i can replicate the issue using only the default assets within a new project.

 

As an example, during a click of the dropdown for the shader selection on a material. Its still going... still waiting. And... there are only the builtin shaders present.

*EDIT* Now timer is at 3:24...

 

Ok, i can post a bug, but... what specifics do i give when it is such a broad problem?

 

Im starting to wonder if you guys should stop pushing unity forward, and, instead *FIX IT* for its current version.

Every version has a bunch of new features to add to the uncertain mess of the current editor *WITHOUT HAVING FIXED MOST OF THE PREVIOUS VERSION'S KNOWN ISSUES.*

Is that how it should be done? Instead of powering on forwards, with old bugs still floating around which have been known but not dealt with? Judging by the state of this thread and the fact that it is not the only area within which this sort of response is happening, i think you guys just need to stop advancing, and settle your footing at the current version...

And stop wasting hours and hours and hours of peoples time. Today, 3 hours after i tried to start working, i am leaving it alone because these issues are so infuriating to deal with, and i cant handle the stress. And to only have the staff repeatedly try and blame it on the code of the users... is disgusting. You make a program, it gets updates, then suddenly users have trouble with things whilst their own code has not fundamentally changed... then that is not the fault of the user, it is the fault of the editor.

Im sure *every* unity user would be more than happy to forego a year or two in tech advancement if it meant we could have an editor *THAT ACTUALLY WORKS*.

If you stopped to work on stability, unity would be the market leader for self contained development software, instead, unity seems set on destroying the reputation they do have.


*EDIT* Apologies for the tone of my message above, but the point still stands.

 

Further update, and further proof that the issue is not the code of the user, is that i just performed a rebuild of the project, and it has solved the problem - without a single line of code or package changed.

The problem appears to lay in the ... messy way that the project folder is left, once an import into a new version happens and...

Well, the entire thing could be dealt with by making the project, when re-importing, *actually* delete all the stuff you dont need. Currently, i am 100% sure that the re-import feature just overwrites everything that is there and doesnt remove old temp files or scripting backups etc that exist within the folder. When the data is left behind from previous versions, it would make things very unpredictable... and that appears to be the major problem here.

Again, apologies for the tone but having spent four hours staring blankly at my monitor and unable to progress with a project that has been my main focus for the last 2.5 years, and having it seem like it may be approaching a point where i have to give it up is... not pleasant.

Please take my words above as advice, free to be discarded or considered as you see fit... and i will send the full project which is still experiencing the slowdowns to the bug reports... The problem could easily be detectable, and, if desired, automatically dealt with, with just a modicum of forethought - tidying up those massive directories frequently, for example.

(My opinion is still that unity rocks! but... sometimes it hurts too )


*EDIT* --- What i did exactly;
Updated from unity 2020.2.3f1 to 2020.2.6f1, but, didnt open the project in 2020.2.6.f1. Then,
I copied "Assets", "packages", "UserSettings", and "ProjectSettings" to a new folder, and *then* opened the new project folder in the new version of the editor.

First play was 15-20 seconds, quite acceptable considering it was only the first time, then 3 or so seconds, and, the aforementioned menu item - material shader selection - opened without any noticeable delay.

So far, no noticeable delays at all.

 

Im gonna await response from the Unity people before i post the bug, as the problem could be solved by either the update or the rebuild, and, if desired i can perform further tests, as the faulty slow project is still untouched.

 

Ok, thats good to hear. Ill get the project sent soon, its... rather large.
(Altho, 95% is the unity added stuff in library etc)

 

I agree. Even when working in a fresh project, doing really simple stuff, it's super laggy. Way more so than previous versions.

 

When Unity is slow, always assume it's Collaborate. It's an abomination.

@Aras, @MartinTilo, we have some slowdowns happening very rarely. So there's operations that usually are pretty fast that very occasionally are super-slow and pop up a load bar.

In those cases, figuring out what's going on is hard. We'd kinda have to always have the editor profiler open, and then hope that we're fast enough to stop the profiler once that happens. Worse, we'd have to have deep profiling enabled and that'd introduce a lot of lags that normally would usually be there.

Is there any way the popup window could dig deeper in the call stack? Or is there some way we could have the profiler better able to help us identify what's going on when Unity's slow without having it be full throttle all the time?

I realize that it's hard, as you can't know that an operation is slow until it's already been slow once. But some kind of "hey, this function has been slow earlier, so since we're calling it again, increase how hard we profile it this time around since it's a likely candidate for trouble?"

 

It is also possible to simply wire the auto-profiling-start when the first hold-on popup evaluation happens (turn on profiling when Unity is deciding whether or not show the hold-on popup and turn off when it hides and show the profiler window). In the alpha and beta builds only and should be configurable. At least we, who care about this, could get you a ton of data to work on.

 

That seems neat, if I encounter again this busy business, I'll use it to check if it shows any meaningful data. Thanks for sharing!

 

This happens to me all the time. Just waited 20 min for it to release itself. using 2020.2.7f

 

See the tools above to find out what's happening and if you find something coming from Unity itself, file a bug report using the actual data you gain using those tools. So Unity can fix the problem. Also if it turns out it's some other code, you can find out what to fix or if it is some third-party, you can tell them or you can decide to stop using that piece of code.

 

Thanks! will check it out!

 

I've ended up starting a new version and transfer all content. seems to works without issues for now. much much faster. Still hope for a reasonable solution, since this project was made with 2020.2.x from the start.

 

Unity 2020.2.7f1 (default render pipeline, Windows 10) - Ok, this is absolutely and painfully awful! And the longer I am using Unity the worse it gets. I thought something was going on so I created a new, empty scene and put in a single 1024 terrain. Took 8 minutes from clicking on the terrain until the terrain showed in the inspector, all the while "Hold On ... " progress bar was whipping back and forth. Just for grins when the Terrain Inspector finally showed I hit File/Save -- took 3 minutes for the "Hold On ... " progress bar to stop. Everything I try

This actually makes 2020.2.7f1 completely unusable. Yes, I know its beta but good grief, 2020.2.6 didn't do this. There seriously must be no legit quality checks or even cursory looks at these releases before they push out a very flawed version. I am a long time Unity user (since the 3.something Mac only version) and I'm seriously concerned about the production philosophy and my decision to go with Unity. It's maddening trying to get things done with flawed version after flawed version. The users while they can be helpful resource, should not be responsible for fixing all this. This entire product (all released versions) really needs a major Quality Improvement initiative overhaul seems like.

I really didn't intend for this to come across a rant : but goodness this is frustrating.

 

Im getting lots of these when trying to close the project, its not especially big.
im just forceclosing the project with taskmanager for now but this is kinda unnecessary.
Unity 2020.2.5f

 

I can confirm that most of these messages come up because of the Collab feature. Disabling that reduces these occurrences BUT that's not a solution at all. If you are using Collab feature, you'll run in to this quite frequently and therefore needs a fix asap or uproot and move to Git instead (which is not practical for most ongoing projects)

 

Every one of the version control assets is slow like hell. Collab, GitHub for Unity, Plastic for Unity, doesn't matter. Simply 'watching' the entire Asset directory tree including full depth and all files is too expensive.
I work more faster since I moved to Azure Repos (part of Devops, completely free for persons and small businesses, unlimited gigabytes, including LFS and everything) and I can handle my commits and pushes and pulls from Rider (but you equally easily can use SourceTree or other Git-friendly tools too). Unity Editor isn't involved. You just need to build a good enough .gitignore file (the .collabignore is a good starting point). This way I can include even higher folders in the VCS. It is worth the work to switch.

 

They're slow if they're watching the asset tree directory.

Git by default only does work when you tell it to. If you're talking about git integrations in the editor, well, yeah, don't use those? It's always seemed strange to me that somebody'd want to open an editor window rather than alt+tabbing to a terminal or git UI app.

The big problem with collab seems to be that it does things that are slow even when you're not using collab, and it's installed by default. They might've fixed that, idk.

 

Are we sure about that?

On my project, collab is off and uninstalled and yet, I have that problem. That said, it' does look a lot like "check for changes" with a new name.

 

We get messages like mentioned in previous posts on a regular basis since we did an update.

We updated from 2020.1.17 to the latest 2020.2.7 version. We did no updates in between.

We did not have these problems with Unity 2020.1.17. I can confirm that.
The problems started immediately after the Unity update and before we updated some package manager files like UWRP later.

"Application.Quit" usually takes up to 12 minutes and sometimes it's enough to check or uncheck a random checkbox on one of our scripts inside the inspector to invoke these messages followed by minutes of waiting time.

We also don't use the collab-features. This feature is deactivated.

Could this be a memory issue?
I have a subtle feeling that my computer is getting slower and I had to force to quite Unity at one point and restart my computer.





after saving the scene

 

I acknowledge Unity freeze problems. 2020.2.4
Every time you open the list of shaders in a material, Unity freeze indefinitely.
I suspect that shaders are being compiled at this point. Perhaps this is due to the old ShaderGraph format of shaders, which are in Packages and we cannot resave them to the new format in any way.

 

I just clicked on "file".

Is there no programmer at Unity who can fix this?

I hope that after lunch the progress bar has disappeared and I can continue working

 

Having the same problem myself. On a fresh new URP project, there's no problems, but in my project, there's around 3min waiting time every time I try to change a shader in the inspector of a material, or closing Unity.

Tried doing some editor deep profiling, but the profiler stopped recording as soon as the "Hold on" modals shows up.

In my task manager I notice the drive going up to around 320 MB/s read speed, to go down to 0 as soon as the modal disappears. Else no spikes or high usage of either CPU, memory or GPU.

Will try to import all my assets and plug-ins one by one until it brakes Will get back in a couple of hours.

(running Unity 2020.2.6f1 on a Asus ROG 14, AMD Ryzen 9, 32 GB memory, SSD, NVIDIA RTX 2060 max-q (but in my tests using AMD Radeon build cause I'm on the battery)

 

Sorry, totally missed that post.

Checking my project, the Library folder was 20gb, (830mb after deleting and reimporting), and now the Shader Selector works again, and only 1sek wait time when closing

Will see if I can upgrade to 2021.1.0b12, else I continue to regularly delete the Library folder.

Thanks for fixing this!

(btw, usually I try to creating a bug report, but most of the time the bug reporter crashes, or fails to upload all files, so I just give up)

 

I don't see this behavior on my (much slower) laptop with the same Unity version installed and the exact same project files but on the contrary I did not have this message boxes with Unity 2020.02.7f1 on the pc at all. Is this strange?

You guys are welcome to take a look via TeamView on my computer if it helps you.

"Hold-on" is greeting me again while I was about to add a color filter right now.

 

Select All Keyframes & change Keyframe tangent

 

Hello,
I've got something new with version 2020.3.0f1.
The same "Hold on..." box appears for some minutes when pressing play mode button, then I've got a chrome.exe error and editor crash and close.

This behavior appears 3 times today, even after a reboot.
Note that my chrome works fine and stay open.
Unfortunately, I don't I have the bug report window so I can't send you a bug report :/

 

Sammmme with me! 2020.3 still has this problem

 

This problem is making my project inching forward,Encounter every 10 minutes or so

 

Unity 2020.2.4
This is not okay ....



I waited around 11 minutes this time. Each action on the editor arbitrary get the "Hold on" window.
At the end, you wait more than making games, this is very frustrating.

 

I tried to open the shaderlist inside a newly created material. At the end (after 35 min waiting-time) Unity closed without warning or the chance to file a bug report and my progress got lost as well.

It happened twice today on the same spot (trying to select a shader). Unity 2020.3.0f1

Since then it worked fine. How could I reproduce such a behavior?

I made all windows updates, deactivated my anti-virus, closed every single task I don't need, updated all drivers and checked my hardware but this boxes just won't disappear. To work under this conditions has become very frustrating I must say. I didn't have these problems in Unity 2020.1.17 with the same project.