Official Editor Progress Bar stalls (request for bug reports)

Opening a simple project, default HDRP template.

Code (JavaScript):

1. New input system (experimental) initialized
2. [Project] Loading completed in 629.344 seconds
3.     Project init time:                 1.547 seconds
4.         Template init time:         0.000 seconds
5.         Package Manager init time:         0.000 seconds
6.         Asset Database init time:         0.000 seconds
7.         Global illumination init time:     0.000 seconds
8.         Assemblies load time:             0.000 seconds
9.         Unity extensions init time:     0.000 seconds
10.         Asset Database refresh time:     0.000 seconds
11.     Scene opening time:             352.469 seconds
12. EditorUpdateCheck: Response {"updateinterval":3600} updateurl =  interval = 3600

from the log file unity is not clear. it took 352 seconds to open an empty scene with a total of 629 seconds for opening the entire project

Unity team, can you look if you have forgotten to reset some internal timer inside you editor that is set to 10 minutes instead of 1 minute or less? Really, it may just be some simple value forgotten somewhere that stop the software loop waiting for something and it always does this for 10 minutes.

 

This issue happened to me on Unity 2020.3.20f1 on a blank project after importing Doozy UI Manager (V4). The editor freezes for 15+ minutes when I open the project or select anything related to Doozy or open its UI Menu. After the freeze is over I can keep working as normal. I do not know what I can provide here to help debug this.

 

For information, I have solved my problem.
For some unknown reason Windows Defender was locking a DLL in the temporary folder of my project, so Unity couldn't rebuild it.
I don't know why it did that, there was no updates and I changed nothing to my configuration.

Telling to Windows Defender to ignore my project's directory solved the problem.

 

The behavior for me is the same in this exact situation (I have unity 2021.1.24f abd same asste doozy 4) is that unity will reimport/reanalyze all assets files when loading the project. It takes up to 10 minutes to load the project.

I've then added to the project ProBuilder and uMotion using the package manager/asset store and it took 30 minutes to import them because it reimported or rechecked ALL the assets already present in the project, Doozy and the HDRP example assets (the room with the chair and plants from unity).

My understanding is that it should had imported the new assets files NOT the existing one.

I was seeing all the files listed under the loading bar, and the editor just listed them one by one. It also took a long time for each file to go be verified. Files are small, but I can see them sometimes for seconds listed under the loading bar. Not sure if an update delay of the loading bar interface or an indication of something wrong.

That asset, doozy, have 15k files. I've not even started to add MY game files, textures, objects.

Maybe unity have this issue when there are many files?

Also each file/asset in the project have a companion "artifact" file created by unity. Those damn "artifacts" files are all over the disk fragmented in small pieces. Like grain of sands all over the place.

Currently for a project that have HDRP starting template, Doozy 4, uMotion and ProBuilder I have 52.175 artifacts files for a total of 2.02 GB of disk size.

Checking the disk fragmentation those files are literally like grain of sands spreaded all over the disk. I guarantee that for small files it takes longer to read you artifact file that opening the original asset file.

It may make sense to have a small reference file for a huge asset, like a model that is 100Mb or something but why not having some internal database solution that is build to deal with small files

Did you did any test to see if this "artifact" concept works when you have 50k or 100k files in the project? Maybe if you have a lot of files then you have a problem.

What are these arifacts files anyway? Do we need them?

 

Hey, so I haven't seen this thread and I created one last week : https://forum.unity.com/threads/uni...-process-that-blocks-editor-loadings.1180099/

The loadings were saying: "Application.executeMenuItem" (if we save a scene), "ProjectBrowser.OnGUI.ExecuteCommand" (if we duplicate an asset) or "Application.enterPlayMode" (if we enter play mode).

To unlock the loading, we are to open the Process Manager, find the Unity process, open the subprocesses and kill the one who is responding (not the one who is unresponding).

When we do that, the popup say "Application.reload" and the loading restarts and work well.

[...]

We also have long "Refresh Asset Database" time when we open Unity (up to 10 minutes), and we can't kill any process during that time.​

Have you had a similar issue?

 

Ok, I have new theory which may have some truth.

Unity will write to the Library folder huge numbers of small size "artifacts" files

At least one reason of these continuous slow downs may be a combination of a normal HDD having some level of fragmentation which increase the chance of spreading the "artifacts" files all over the disk. And also break those artifacts files in multiple pieces.

So, when you start adding files to project the number of paired "artifacts" files grow, they may be hundred of thousandth of those files for a normal 3D project. Those files end up like grain of sands all over the disk and they will also will be fragmented.

You can check this by using a defragmentation software that shows location of the fragmented files on disk in a graphical way. In my case they were all over the disk exactly like sand between other files.

For example on the project I'm working which have only the HDRP setup and DOOZYUI4 I have around 50k of artifacts files. I still need to add a lot of files and asset to the game so I predict getting to higher number or artifacts soon.

So 50k divided by an average of 3 pieces, we have 150k of small pieces all over the disk. When unity starts (or for some other reason during editing) it needs to read all or part of those files. On a normal HDD this will take minutes as accessing and reading small files is very slow.

I've moved the project to a SSD (yeah I know why not thinking before about it) and the loading times and interruptions appear to take less time. Instead of waiting up to 8 minutes to load the project now it takes 1 or 2 minutes which make sense because the SSD is faster in reading small files.

Now I've got tricked in thinking a normal disk may be fine because is a slow build if you disk is not fragmented and the project starts with a small number of files. But once you start adding stuff and the fragmentation increases, you slowly build up to this issue.

edit: sorry for posting this two times, I've posted this in another thread, wanted to post it here

 

In my case it doest recover at all even if I wait for an hour... It get's stuck with the "Reload Script Assemblies" dialog forever... Is still the same problem ?

Currently using 2020.3.20 on MAC bigsur 11.6

 

Couple of days later I think this fragmentation problem may had been the issue. I'm not sure if the editor still writes or reads files without any apparent logic behind the operation. If it does, it is not visible to me at the moment

Opening the projects works fine and fast. I can even keep 3 editors (of different versions) open with 3 different projects at the same time and switching between them works ok, no blocks or delays. All are on the SSD off course.

So if anyone have this issue, first check your HDD fragmentation, if you have all those artifacts files all over the place then get an M2 SSD. You don't need an expensive one, one that have 128Gb probably will work fine, I think it depends of how heavy your project is/will be, if you need more storage.

 

I am having this problem of freezes on both Windows and Mac machines, with 2020.3.21f1 and 2020.3.22f1. See https://forum.unity.com/threads/hangups-on-macos-unity-2020-3-22f1-lts-editor-memory-leak.1194184/

 

I had no issue on this project in unity 2019.
I'm on SSD

But yeah, the Artifacts folder is bigger than the Assets and the .git folders combined x)

 

Random thought of the day related to import hangs:

Every now and again I attach the VS debugger to the Unity process when this happens to figure out what is hung. As is usual: it's hung on mono_os_mutes_lock

In today's adventure the source is from the collab plugin accessing AppDomain then The Assemblies, and calling https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.reflectiononly?view=net-5.0

Whatever happens in that function - specifically the getter of the property (I assume looking in another assembly?) causes a lock on the main thread which is never recovered. It appears to be loading the Assembly class specifically causing the lock.

In 99% of times I've looked in to this it is always the same situation but from a different source.

 

Are we all using Collab? I am.

 

Collab's getting killed off now, so it's time to switch to a proper version control system.

It wouldn't surprise me if Collab is the culprit of a lot of slowdowns since it was always bad at everything

 

Collab is not getting killed, is just changing the name for Version Control and some features are being added.
But yeah I will not argue that is a very good version control system.

 

It's not specific to collab, it just happens that collab leads to calling into other, possibly not fully loaded, assemblies. This is why people often point fingers at Odin - lots of assembly reflection stuff happening.

In most of my projects collab has been removed. It just happens that today's testing was not.

 

Yes it is. https://forum.unity.com/threads/collaborate-will-soon-be-upgraded-to-plastic-scm.1188592/

 

We just moved from collar to Plastic and yeah... it keeps happening

 

Well... I am in here too because of these same problems. My project has become almost unusable/non-responsive on my two work PCs. I think what Unity really needs now is in internal "task manager" window that shows all running Unity processes with status bars. I've used tools like this in the past (mostly in e-mail apps) whenever the network appeared to be stalled. It should probably even be built in to the "Hold on" dialog or something to be able to easily identify if two processes are competing with each other.

 

Today i got a stall on Quit, this was a new one, the only option was force killing the process.

 

do you have the project on a SSD?

I'm just curios why I managed to fix this by moving the project from a heavily fragmented normal HDD to an SSD

 

A fragmented file is literally stored on the drive in pieces instead of one contiguous block, requiring the drive head to jump around randomly as it reads the files, which is much slower. A normal HHD is also MUCH slower than any SSD. The "Hold on" box went away because the display threshold is above the time that's needed to read your files.

 

yes, but some people who say they have this issue they said they have SSD. so either they don't actually know if they have SSDs or normal HDD or I'm wrong about my theory that heavy fragmentation together with hundred of thousands of files generated by unity is the fault here

 

Yes, I have this issue and I am using SSDs on both PCs. The dialog box itself isn't a problem - it's if Unity is hung up on some process that's making the Editor unresponsive. So it could either be a slow, fragmented drive, or pretty much a dozen other things that could be wrong with your project. Seeing a simple dialog box is really a broad and vague issue, which is why Unity needs an internal process viewer so we can see what it's actually doing when it's unresponsive.

 

I'm also working on SSDs exclusively and i don't think it's related to that as it happens so randomly (and when it happens that it never recovers), it's more likely something locking up internally.

 

What options do we have to fix Unity? If I remember correctly, this wait-issues started with Unity 2020. Me and my team has experienced this issue for about 2 years now in different projects and different computers.

It's also really a bad UI design to show popup-modal windows in 2021. It's probably the core-parts of the editor that shows it's age?

By upgrading my simple test project to 2021.2.5f1 the annoying popup timer window went away in just 4 seconds (empty scene on a 12900k CPU) - It was about 8 seconds with Unity 2021.1.11f1

 

Read the OP, check what's happening, identify the problem, if it's something in your code, fix it, if it's something in third-party editor script either fix it or ask its developer to fix it, if it's something Unity is doing, submit a bug report...
You can also set the latency how much time should pass before the dialog shows up.
And obviously have all the project files on SSD.

Also: make any Unity or project folders an exemption from any application which observe or can block files like anti-virus software, defenders, etc. Nothing should observe these files except Unity.

 

While I can understand the logic behind this argument, is not good practice, because malware may infect files in those folders. Unity as a software needs to work with antiviruses or defenders or the rest. Which they probably do, to be fair.

These hold on message errors may be something that is so hard implemented inside the software that by this point unity chose to ignore the issue, move on to newer versions and hope people will slowly fade away from using the 2020.

 

- project files are low-risk files, vast majority are text or image
- there is nothing in there what at at least one point wasn't somewhere else scanned by said software
- obviously if your computer infected, you will scan and repair your entire computer, but then slow progress bar is your least problem
- it is virtually impossible statistically that your computer is infected, but only your Unity files get infected, nothing else, what could alert you to the problem (BTW, stop clicking on shady things on the internet and opening files from unknown sources and you basically cut your risk to hundredth of the original)

Aham... it doesn't look like they are ignoring the issue. At least to me. Maybe our definition of "ignore smthg" is different though. Asking for reports about the problem is the opposite of ignoring, in my book.

 

They have asked for reports 6 months ago.

No answer till then. I will go with my "ignore and let it pass" theory for now. If they could had fixed this easily they would had already did it.

 

I want to add that I didn't experience this problem anymore from the moment I've moved all projects from that heavily fragmented normal hard disk to and SSD.

I've looked at the files from the unity projects in a defragmentation software that show the location on disk and there where probably 300k+ fragments all over the disk like sand. This made sense to me as accessing all those files if unity wanted to access them all or at least a significant part could take minutes.

It also made sense because moving the entire project folder to an SSD (so a "read operation" on the normal HD) took around 6 to 8 minutes.

After I've successfully moved the folder I've deleted the files which took windows another 7 minutes (so a "delete operation")

If unity decided, for some reason to update those small files (so a read, delete, write operation) the editor would be blocked for around 10 minutes+ which makes sense.

The files I'm talking about are those located in

"YOUR PROJECT FOLDER NAME\Library\Artifacts

So I don't have the issue anymore (after probably 8 months of struggling and even abandoning unity for months because of this.

Before I did this I was not able to work on the editor because it remained blocked at random for 10-15 minutes at the time maybe two-three times an hour.

After I've moved the project, I can keep 3 (three) unity editor open each with three projects open and all work fine. The same projects that had issues on the normal HDD.


I have 3 editor/project opened because when dealing with this issue I wanted to rebuild the project that had the issues so some stuff I need is in one project, something else in another, so I want to consolidate them in one project. Except I was remembering where everything was or how was set up so I kept multiple projects open to verify.

I'm saying that unity could chose to ignore this issue (IF is a fragmentation issue/coupled with unity writing massive amount of data) because there is nothing they can do to prevent the files getting fragmented. And most of high end users that pay for the PRO version would have fast SSD installed. So what they could do? How to you fix a fragmentation issue?

 

What editor version you are using ?
For how long you have the projects running now on the SSD ?

If not yet, try working for a few of days and see if it will brake again !

I am using a pretty decent machine with 16 cores CPU, 16 gigs of ram and a M.2 1000GB SSD and i have this issue even on brand new projects. All appears after i add some tools like spline editors, environment tools etc...

Also, for me it is not always related to I/O operations but to CPU time, like CPU is executing some editor Code !

Unity 2021.2.x doesn't fix it for me nor the latest 2022 beta !

 

At the moment the editor is 2020.3.22f1.

I've worked on and off for around a month. October till November. works fine for now.

I actually discovered this issue because I've created an empty project, imported an asset named "DoozyUi 4", and this asset installed 15.000 files, and this got the editor to experience the issue immediately.

While normally it was a slow build because you don't add so many files immediately in a project.

I've said first, what the actual f.. the author did here with all the files. Then I've noticed that unity create a companion identification file for each of those 15K file (the one from artifacts folder) Then those 15K artifacts companion files become 75k+ fragments. For some reason unity decided randomly to read all or maybe part of those files, got the holdon loading bar for minutes.

I've put an SSD in the computer, moved the empty project with that Doozy asset on that drive, no more issues.

Ok please verify something first.

How many files do you have in the artifacts folder on the project that has issues?

 

Annoyed that I just found this thread just now.
But I've been having this issue in unity for MAAANY months now.
I have been updating unity all the way from probably 2021.1.15f1 all the way to 2021.1.27f1 hoping that this issue was going to be fixed in one of those versions. Absolutely nothing.

But it seems like this thread existed for a large chunk of me having this issue. So I'm glad to know that the Unity devs are aware of this issue.

I made an initial post about this in september of 2021
https://forum.unity.com/threads/lau...mporting-busy-for-xx-xx.1166429/#post-7501084
but had this issue for a few months prior.

When I launch unity for the first time (on a particular day, booting up my pc) the loading bar will freeze on "Importing..." and never go anywhere.

The key identifier of the issue is that if you wait about a minute, force quit the program. And relaunch, it opens fine.

Theres nothing in the log file that necesarily indicates where it's getting stuck.

The last lines in the log file are

ExitCode: 0 Duration: 0s649ms
*** Tundra build success (0.56 seconds), 0 items updated, 770 evaluated
AssetDatabase: script compilation time: 1.401324s
Begin MonoManager ReloadAssembly
Symbol file LoadedFromMemory is not a mono symbol file
Symbol file LoadedFromMemory is not a mono symbol file
Symbol file LoadedFromMemory is not a mono symbol file
Native extension for WindowsStandalone target not found
Refreshing native plugins compatible for Editor in 181.39 ms, found 6 plugins.
Preloading 0 native plugins for Editor in 0.00 ms.

If I force quit and relaunch, the lines that would follow this are for logs for custom scripts that run when unity is initializing
with the [InitializeOnLoadMethod] attribute (or whatever its called)

But It's clear that this issue is due to something involved with asset importing.
And other people saying that it's related to trying to import an asset that is "out of date"

EDIT: I have also made a bug report just now
Here is the ticket id
1389903

 

Fragmentation and a fast SSD are not the only things at hand. This I can assure you.

 

When I have the issue, I go to the Process Manager (windows) and often have two Unity processes: one that doesn't respond and another one running. I kill the one running and it unblocks progress bar.

It doesn't work on the progress bar related to Unity starting up but does work for OnGUI processes, StartPlayMode, starting a build, etc.

Still. It makes us lose a lot of time (when we don't see it), do Unity have any idea how to fix that?
I don't have the issue in the previous Unity version.

 

When you say you force quit the Unity process that is running, is that one of the "child processes".
So for me I have:

Unity Editor (4)
Console Window Host
Node.js: Server-side JavaScript
UnityCrashHandler64
Unity Editor [not responding]

You close one of those child processes?? Is what you're saying?
If so, which one exactly?


Also what version of unity are you using?

 

The problem still persists on 2020.3.22f1.

 

Unity compressing the script file?? why??

Unity 2020.3.25f1

 

Guys remember to send the Unity QA team your bug reports and projects.

On my end I downgraded from 2021.2 ~> 2021.1 and notice that the editor is WAY more responsive, especially after exiting play mode. In 2021.2 there is a whole scene repaint calculation that happens after exiting play mode, which takes up to 10 seconds to give me back control

 

So Unity is waiting for bug reports and can't come up with its own?? They have (hopefully - but doubt it recently) QA staff and the freaking source code. Who could get more insight into this problem - my bug report or you and your QA staff? Besides i am not paying Unity for treating me like a beta tester. This bug is so serious that it should have been fixed years ago with or without any reports.

And please spare me the BS that you have troubles with a repro case. So many people have problems on the spot by just clinking somewhere while you all have a hard time "catching" that bug - it's unprofessional and embarrassing really!

So if this whole thread isn't a lame approach to delay things further i don't know what is.

 

One thing that oddly seems to have improved the issue for me a bit is to run Unity as administrator. Performance seems much better after doing so.

 

Any progress on this issue ? I'm using unity 2021.3 LTS and the random stalls make any work impossible. I've been stuck the whole afternoon because sudenly, after I added an empty class unity decided it had to reload the assemblies for hours every time i make a single line code edit (I work on a very basic mobile game, 50 files, barely 5k lines of code, packages using assemblies reference , no static... Applied every possible recomendations to avoid long Assemblies loading time... Workflow and porductivity is ruined.).

 

FWIW I've had these happen seemingly randomly, on both work-related large projects and hobby small ones.
Both on 2021.3.0f1 using URP with the only 3rd party plugin being DoTween.

I found :
Turning off Project Settings -> Burst AOT Setting -> Enable Burst Compilation greatly improved my iteration times.
Removing the Version Control package improved Editor speed and stopped the Editor occasionally hanging (switched to using standalone Plastic client).

 

Currently stuck at a really slow stall screen on 2021.3.5f1 LTS. I've had to force quit it because my memory (RAM) usage was at 98%!

It stays stuck at a window called "Importing (iteration 3) com.unity.scriptablerenderpipeline ValidationExceptions.json" or something like that.

It's been stuck for over 2 hours loading this gosh-darn file on startup trying to convert a large project from 2021.3.1f1. I'm on a Windows 10 PC, 8G RAM.

 

if you convert a project and it has a lot of files and shaders maybe it just needs time. all these game engines calculate and prepare shaders and honestly I don't understand what they actually doing will all these millions shaders everywhere.

check if CPU is used and if unity is reading writing to disk. if you get this loadign bar randomly when you are working on a project it most likely the bug, but if you are converting projects or importing assets and the rest. it usually takes time. or is just the bug

 

No, I'm good. After force quitting, I tried again. I let it run overnight as I slept and now my project is open and all's good. I'm surprised there was no corruption due to aborting the task using Ctrl-Alt-Del the first time.

Thanks for the suggestions though!

 

Unity 2021.3.0 and 2021.3.6, getting stuck in export, upload to store, even moving the camera in the scene can take a minute to update etc

This is not just bugs, happens all the time in all my 2021 projects, is just Unity not working. There is no reason to check it as a bug, must rewrite the Unity editor to work faster, this is huge work and not a bug fix, that is why prevention is the ultimate solution, stop adding new things and make sure the editor is lightning fast first, then add and check again.

I have 10x bigger projects in Unity 2018 and was lightning fast in everything, is just that the core of Unity has increased exponentially in complexity, the pipeline shaders for example can take forever to build etc

The editor is also extremely heavier without any visible changes or reason, is just taking something perfect and slowly breaking it in upcoming versions.

 

I have really bad news for you, in your case you just have the infamous bug that unity doesn't want to admit they have. I've actually abandoned my project and unity after two years of work and moved to unreal because of this.

First time I've got this I've found no solution to make it work fine again, and I've created a new project and slowly moved the assets from the bad project to the new project.

After this painful and long work the new project worked for some time. That was November last year. Then again this damn bug appeared out of the blue.

It got even worse than waiting for 20 minutes at the time randomly. When hitting save scene the editor appeared that it saved the scene, removed the asterisk on the title bar. But horror, it didn't, lost one day of work because the scene was not saved. The editor even closed without telling me that the scene is not saved.

From that moment on I could not trusted the Save button. I've closed unity and got depressed. Was really angry and sad about all this time wasted. This thread here didn't help, unity staff ignores this issue.

Anyway good news is that I've abandoned unity and moved to unreal and I've managed to advance in my project. Took a couple of month to figure that engine, hard work but is better than waiting for this broken mess to be fixed.

 

7 hours wait before killing Unity, to (not) export around 400Mb project.

This happens to every single Unity 2021.3.0 or 2021.3.6 project i have, is not per project, is a massive bug overall or maybe system wide something affects it ?

This above is another project that got stuck too.

The thing is Unity 2019 works fine, so something was broken (as all things in Unity get broken, exponentially more complex and vastly slower in newer versions)

I have decided to just use RAR to zip my files and that is all, there is no longer export function as far as i am concerned and have to work around this.

This delay can happen if export only a single file btw, is not just for 400MB the problem.