Just wondered if these will go away? present in 23 and 24, or if it’s something I’m being incredibly naughty about in this relatively slim project…
12 Likes
It’s intolerable, I guess it might be collab or something, will try rolling back.
4 Likes
I’m getting them too (and also using Collab, but I’m not convinced that’s the reason)
Are you talking about the “overhauled” progressbar that displays “busy for” now:
I like the idea of displaying progress! I mean, I prefer seeing an indicator that Unity is busy, rather than an editor freeze with no feedback.
That being said, I would of course even more prefer if Unity would be fast, so I don’t have to stare at “busy for” and could actually work.
PS: I see this progressbar with “busy for” for a lot of things in Unity, like opening project, opening scene, enter playmode, etc. That’s a nice improvement for me 
I would also prefer if it display “Please wait” rather than “Hold on”, but I guess they have way more important things to do 
EDIT: A nice improvement would be if that “Hold on” progressbar would not appear immediately, but after 500ms. That would workaround issues where things are fast, so you don’t see a progessbar for operations that finish in a split-second, thus being easier on the eye.
12 Likes
i’d hope that it can be toggled off…
when working with some small test projects it gets annoying to see that box flashing for 0.01s every time…
and its so fast that you cannot read anything there anyways…
also if you alt tab away after you press play, then whole unity starts blinking in taskbar…
3 Likes
Agreed.
I had the same problem in several tools I wrote too. My solution to this problem was to display the progressbar only if the operation lasts more than 500ms. That removed all the progressbar flashes and only showed progress for operations that actually took longer, where showing progress is then useful.
Perhaps Unity could implement this too.
3 Likes
But these things… weren’t taking up time before at all.
Basically I stopwatch timed it from the earlier version and this stuff is additional time added for 0 reason. It’s much slower/more disruptive so I had to post.
I mean even switching to another window (0 saving, 0 compiling), it pops up this stuff and makes me wait for 5 sec where before, zero wait.
Honestly, if it goes live like this, then 2019.3 LTS will do I think… hoping its just other packages or something causing it.
20 Likes
While liking the progress bar addition I’ve noticed more waiting around too
2 Likes
It kicks in whenever anything happens. Even clicking an object will trigger it sometimes, it’s a bloody nuisance. It’s probably automatic, and if so I’m wondering why. I’d love to know why in an age of multi threading, this thing would happily block things that weren’t blocked before.
Don’t see a single thing I like, or even need to know. I mean getting used to a cog or discreet progress bar in corner is way preferable.
11 Likes
I mean, I don’t know. What am I supposed to get out of that?
I now know that Unity spends a few seconds randomly in Application.Tick , Application.Messages and SceneTracker, and also I used to say that “Checking for Changes” took a couple of minutes, but now I know it’s over 3 minutes.
And with all that information I now also know that in the time it takes for my project to open in 2020, I can open and close the same project in Unity 4.x around 100 times, which feels… …
What am I supposed to do with that information?
If I was any more negatively predisposed against Unity I would say it’s some sort of bizarre power move (“LOOK WE ARE MAKING YOU WAIT AND THERE IS NOTHING YOU CAN DO, HAHA”)
4 Likes
I have the same issue.
It’s bad on 23, but it got unusable on 24 so I rolled back to 23 for now.
Using AssetDatabase.SaveAssets() after dirtying a single tiny ScriptableObject takes almost 20s on 24, and takes about 10 on 23. Looking at the profiler in 23, it goes up to 2.5GB RAM (!) to run SaveAssets()
Before, it was nearly instant. Something definitely happened in recent versions.
Found the culprit for my case: QuickSearch 1.6+.
1.5.2 is fine, but 1.6 is sorting a very large array or list and is causing all this. Will post on its threat soon.
That’s a good point, I would prefer it too.
What I get out of it is that I can see that Unity didn’t freeze, but is still doing stuff. I often had the issue: “Alright Unity, you locked up for a minute already, you dead?”.
Probably just a bug.
If it’s related to the progressbar and I have to guess, I would say the progressbar is updated every iteration of work, rather than in timed intervals. I wrote a blog-post how updating a progressbar often makes your program significantly slower and show solutions that don’t suffer this issue:
http://web.archive.org/web/20160804220745/http://console-dev.de/?p=447
1 Like
There’s no bug. Or if the’re a bug, it’s like for an extra 30% difference in slowness.
I’ve gone from being able to open my project and do work in a few seconds with Unity 4.x and Dropbox to a few minutes with Unity 20XX and Collab.
But in any case, we’re getting off topic, since these are not specific to 2020.
I maintain that unless I can do something about it, letting me know (in a shortly flashing panel that I may or may not have time to read), that Unity is wasting time for Application.Messages is absolutely useless.
2 Likes
It would be better if the progress bar is part of the editor and not a popup.
4 Likes
I’ve added it. It’s this item in the release notes: “Editor: Windows Editor pops up a progress indicator automatically, whenever the editor is not responsive for longer than a second”.
Now, if you see it popping up “immediately”, that sounds wrong. Would love a repro.
It already only shows up after 1000ms of non-responsiveness. But absolutely, if you see it popping up faster – would love a repro.
Please file a bug (maybe some package makes “everything” slow down? etc.). In all our testing we never saw that situation – the progress dialog itself is not making things “slower” (it runs on another thread with very little work), and only kicks in after the editor is not responsive for >1s. If doing “anything” in the editor makes it not responsive, well we’d better find out why it’s not responsive; the progress dialog just tells you “hey I’m not responsive” but I highly doubt it’s the culprit.
5 Likes
Well, if it’s non-responsive for 1.1sec the dialogue will appear for 0.1sec, making it seem to us like it’s flashing and popping in and out.
So the question is, why is the Unity editor non responsive for longer than 1 second so often.
6 Likes
We have objects that rebuild the mesh and this takes no time at all. We also use raycastcommand jobs from time to time… I don’t know if it’s relevant or not.
Without this feature there is 0 delays.
With this feature we are being delayed! big time. I think you should make it 100% optional so I can entirely disable it. “Unresponsive” editor detection seems totally broken here.
I mean, I get it pop up and delay me for 2-5 sec just because I clicked away from the shader editor window to the scene view. That doesn’t sound right at all.
It occurs when I’m also doing nothing at all! Got no choice due to work deadline need to roll back, but please make the feature optional at least.
I’m not sure why it is automatic either, surely a developer is best off subscribing to this system on a need-basis. Having it always running seems like a point of failure.
3 Likes
Yes. You think this progress dialog should be removed and go back to how it was before? (i.e. no progress indicator when the editor is stuck) Or the timeout be tweaked? Or made configurable via preferences?
Yup. And, is it non-responsive more often now, compared to how it was before.
In my daily usage, I do get this dialog when entering play mode, or compiling scripts, or selecting many complex assets for the first time, but I don’t get it “all the time doing trivial operations”. So, would be great to know what is different in your case – is it some editor/package code that adds itself as a listener to “many” editor operations and does something expensive? etc.
Hmm. I highly doubt this feature is the thing that’s causing the delay (we haven’t seen that behavior in any internal testing, and logically I can’t think of a reason why it would be causing any slowdown at all). Can you send a repro?
2 Likes
with default empty scene, it appears for about 1.2s, which is still so fast that you cannot read anything (so its not useful in that short time)… i’d prefer if its possible to disable it. (can be useful for debugging hangs, but in daily use would get annoying)