Since upgrading to the new editor (2022.2.0b8) and entities 1.0.0.exp.8 iteration time is a lot slower than before in any project (Samples or my own).
It takes a long time while the unity load bar shows: “Completing Domain”.
Does anyone experience the same?
No, and haven’t heard from anyone else having that problem. At least not always. I had very few occasions where the bar just hangs and I had to close Unity.
To find out what happens, open the Profiler and switch from Play Mode to Edit Mode. That way you can debug the profiler and you should be able to see what’s taking so long.
Same problem here. It takes almost half minutes to compile when I change code in sample project.
Thank you @Enzi , I tried but during that time, the profile is nonresponsive (internal and as a separate process) and only starts working again once the Completing Domain phase is over.
So at the moment, I am at a loss on how to investigate this further.
I could Identify that it is PC architecture dependent it seems (or at least it’s not project related).
Cloning the same project on two different machines leads to \very different times needed for Completing Domain.
One machine is Intel the other is AMD, but they have roughly the same speed for compilation of normal projects, yet in 2022 they differ by 3-4x
Hi, I have this problem too!
I just jump on Unity 2022.2.1 and ECS 1.0.0 pre.15
I always work without the burst compiler. and my reload time is +/- 10sec.
But sometimes I do enable the burst compiler to test some things and the next time I did a script modification and then press Ctrl+R to reload domain… It took me 10sec to reload and +/-3min of ‘‘Completing Domain’’ freeze.
This was not happening before Unity 2022.2.1 and ECS 1.0.0 pre.15.
Anyway, I will keep the burst compiler disabled for now 
Hi, I had the same problem.
For me pressing Ctrl-R during the “Completing Domain” Window forces Unity The reload the domain. That sometimes fixes the problem and shortens the time to wait.
Every Unity developer I know has encountered this, for about two years now, and it’s really sad that there’s not at the very least like a band-aid fix that could show a button to try reloading the domain if it goes on too long. Not a forced timeout, but if you feel it’s taking longer than it should, you could have a button on the dialog box that would restart the process of reloading the domain. Instead, we just have to force close Unity and likely lose progress on whatever we were doing in editor, which gets especially aggravating when you’re jumping in and out of your code editor tweaking certain things.
Not to mention there’s no clear indication that it’s even stuck. I could leave it running for a few hours and it’d still be stuck, but it’d look no different than if it was just taking too long. It’s unforgivable that the only solution is just “force close Unity and lose progress because there’s no auto-saves or recovery process either”
Running into this problem on 2022.2.6f1 and it’s quite annoying. Super long iteration times are quite bad for productivity, but that’s what I am getting.
My iteration times vary from
7 seconds - if I’m editing a top level system assembly that doesn’t cause a subscene rebake
to
over 2minutes - if I edit a low level assembly that everything depends on and causes a subscene rebake
The low level assemblies don’t get changed much now that they’re setup, but because of this I do have separate projects setup for them where I can work without causing long iterations.
so TLDR: use assembly definitions, have separate projects for core/low level assemblies.
Any fix for this? I too am running into this problem.
It’s the same here. Very slow iteration time. Every change takes a very long time to recompile even with the domain reload flags off.
Starting the project takes like 5-10minutes to load up (that’s an empty project from their URP 3D template). I’m talking about opening the project when it’s been generated already.
Recompiling any C# change takes 15-60seconds on this one as well. I have entity systems window open and subscene with one gameobject in it and the authoring script, which is empty. No job is being done, and it’s horrendous unfortunately.
For me this happens badly with synchronous burst, not too bad but not amazing with asynchronous burst, and great with burst off.
This is a per-machine setting, which would explain it being different between computers.
It’s a known issue in burst that unfortunately requires a very fundamental rejigger (moving burst out of process when compiling for the editor).
I thought it’s already like that at the latest burst version?
No, that’s only for player builds.
I’ll try running it with Burst off completely and see if anything changes. Thanks.
However, I don’t know if that changes any startup project time. Though it might be doing checks/burst recompilation there as well. Cuz that’s very slow too.
Yes, it will do bursting on startup, especially with synchronous burst on.
At least in the earlier 22.2 versions, sometimes domain reload thread-locks. I know this because I can see all threads in the Unity process idle and not consuming CPU resources (or very very little likely due to spurious wakeups). Not sure if this happens in later versions, as Pre.47 is broken for me, but my point is there might be two separate issues at play. The thread-lock issue happens regardless of if Burst is enabled. I usually have to kill the process, and then reopening I get an error about multiple instances of the same subscene, after which it seems the editor corrects itself.
I used to have this A LOT but it has gotten much, much better.
It must have something to do with the structure of the project/systems and baking, plus burst.
Seems to be that disabling the Burst in the editor speeds it up a lot. I’m not really seeing any benefit to having Burst enabled in the editor during the dev time especially. It’s such a drag to the whole iteration. I understand the benefits of Burst which are amazing, and it MUST be enabled when optimizing/testing a build/performance, but it’s a killer of iteration unfortunately.
Thanks for shining the light here. My iteration speed went from 30-60seconds to 5seconds max per compile. Don’t know if it’s just a luck, but for now it’s amazing.