Editor is taking 20 seconds to enter playmode in an empty scene

Hi @optimise!

Looking at the bug status I don't think so - it is still assigned to a team and is in work.

 

Hi @Baste ,
Thanks for trying 2018.3!

Did you have Timeline View open? It should be generally ~10MB per frame in deepprofiling mode and ~4GB for enterplaymode frame with 20MB samples.

This definitely sounds like a bug - we've been testing profiler with very large projects on enter playmode (20M samples) and didn't see that. Would it be possible to file a bug - this should be fast to fix with a repro project.

 

Sure, I could do that. Could you PM me a cloud storage link? Rather large project.

I think I had timeline view open when I entered play mode, and then switched over to hierarchy mode to see what was going on.

 

I would recommend having hierarchy view open when using deepprofiler (for now)

 

Is there any progress on improving on enter-to-play mode? As project size gets larger, it is getting really ridiculous and it's killing productivity. It's really a cancer causing.

This is by far the worst problem working with Unity, period! Yet Unity has no solution but blaiming Asset developers(Joachim did say that). I'm hunting Asset develpers down one by one but it's too much work and many don't listen.
If you are going to keep on blaimng the Asset developers, please put some strick restriction for the AssemblyReload at the store submission.

And I know you said something about resetting scene instead of reloading. I'll take anything at this moment if it can help. Any early preview fix will be appreciated.

 

Here are a few of my answers regarding EnterPlayMode issues. I would fire up the profiler and check what's slow. It's explained in the first link.

How to measure what's slow in EnterPlayMode. What's missing in the video is that you should also try to enable "Deep Profiling" to get more detailed information.
https://forum.unity.com/threads/really-slow-to-enter-play-mode.468963/#post-3056065

The number of GameObject's in a scene cause the editor to slow down a lot. See "EnterPlaymode" on this page. If you use asset store plugins that to spawn tens of thousands of game objects in the scene, this does not scale with Unity. It's a known limitation for years.
https://forum.unity.com/threads/5-6...e-of-open-savescene-and-enterplaymode.447500/

(Runtime)InitializeOnLoad can cause EnterPlayMode to slow-down
https://forum.unity.com/threads/enterplaymode-slowness.526819/#post-3636661

Loading scenes in parallel can cause EnterPlayMode to slow-down
https://forum.unity.com/threads/how-to-reduce-enter-play-mode-time.484279/#post-3155183

How EnterPlayMode is affected by adding more assets
https://forum.unity.com/threads/how-to-reduce-enter-play-mode-time.484279/#post-3155777

 

Thanks but I did everything I could to minimize the load time. I have more than 60GB Assets and Unity simply just cannot scale up.

It's pure BS how it is left like this for all these years, yet they talk about Performance by Default.

The problem is that it shouldn't reinitialize everything every freaking time it tries enters the play mode.

UE always enters the play mode instantly no matter how big your project is and it's been working like that more than 10 years.

Why Unity can't fix the sh** that makes it the most unproductive? And it's eating everyone's life away everyday.

I'm sick and tired of dealing with the mess they created.

 

Do you know if the problem in your case is the number of GameObject's in a scene or the number of assets in the project?

 

I've been recently trying to run the deep profiler to understand why things are taking so long. It's about 14 seconds for me, 30GB of assets, scenes that have about 100-200 GameObjects (not created by assets).

I've found two culprits so far (well I don't know if the asset itself is to blame), but people can follow the progress here for:

Rewired: https://forum.unity.com/threads/rewired-advanced-input-for-unity.270693/page-104#post-4426885
Odin Inspector: https://forum.unity.com/threads/rel...ate-workflow-tool.476949/page-16#post-4426891

I'll post a summary back here when both of those threads conclude.

I've been struggling with this a lot. I've promised to never use Unity again when I finish this project, its been 4 years of time at night spending maybe 30-35 seconds on average to test a simple code change. I don't know how much time I've spent over those years waiting for Unity to just recompile+enter play mode. I appreciate the work that Unity has done to make it possible for me to make a hobby dream come true, I just wish they used their own engine to try and release an actual big-ish game. Not a cinematic, not some ECS toy project, not a mobile Flappy Bird clone, but an actual game (use Xbox One S as a target).

Unity could benefit from that experience of using its own tools, then we all would Other engines got massive steps forward when their developers were forced to use them for more than toys.

 

Any update on this? I also started going down the rabbit hole which is `reload assemblies`. It takes 8s while compiling takes only 0.88s.
How can I avoid this? Every minuscule change takes 10s to be applied, that's _really_ bad!

 

The experimental EnterPlaymode without domain reload will be available in 2019.3 alpha. That should save some time in case scripts didn't change, but would cost scripts changes to support it.

Please make a profiler capture (with Profile Editor) and check if you can see any calls related to your or package code.

 

That's going to have to be an optional toggle. I'm really in favor of not having domain reloads when entering play mode, but since that will keep values of static fields around, it'll break backwards compatibility hard.

It's one of those "great idea for new projects, should not be used in large, old projects" kinds of deals.

 

Yes, definitely! It is opt-in Editor ProjectSetting. We can't make it default for now as it changes the behavior. As mentioned before there are 2 major behavior changes in scripts lifecycle - no statics reset and keeping existing object data (fields marked with [NonSerialized] remain).

I would say it depends on how much time team is interested to commit making changes in the existing project
We've tested it on very large project and it required quite a lot changes (~700 lines of code), but the effect was quite significant for artists - 20s -> 2.5s.
We would like to collect the feedback during the alpha/beta phase and see in which form this mode should exist (e.g. extra play button or default mode) and should it exist at all. So far our expectations are that it might save time in 2/3 of cases when entering playmode (based on Editor stats).

 

For future readers, after lots of tests, here is what I did to manage to go from 9-10s to 6-7s in the compile/reload times:

1. Moved imported assets and general tools into the "Standard Assets" folder (name has to be that)
2. Removed as many files as possible (I went through and deleted all the Docs/Example/Demo folders from the assets I was using), their size is not necessarily important
3. Removed default packages which I didn't need: Ads, IAP, Analytics, Multiplayer, XR Legacy, Memory Profiler (you can always bring them back whenever you actually need them)

Notes: if, for some crazy reason, someone doesn't use the attach debugger feature in VS-Unity, disabling the "Editor Attaching" from the preferences, actually makes the reloading quicker (about 0.3-0.5s for me).

Other crazy stuff I found:

Unity seems to spam registry calls for certain player prefs, if they are not found, it will still try and try and try. Using process monitor, you can actually find the key and create an empty one in the registry. Little bit of a hack but worked and it stopped wasting time there.

As a side note: it turns out Unity loads the verdana(b) fonts every single compilation, it only takes 0.003s but yeah it adds up

And now, I can finally go back to develop in peace

EDIT: Posted a little tutorial/post about the adventure: https://gamejolt.com/games/talesofk...attempting-to-decrease-compile-times-she9y7qf

 

Hi, @alexeyzakharov
I just tested the "Instant Enter to Play Mode" preview in 2019.3. It is really amazing! That's what we've been waiting for all these years and finally, we have some hope. Many kudos!

After seeing the possibility, I cannot simply wait much longer. It's doable and but assets need to make some adjustments to take advantage of it.
Since it's an optional feature, why can't we bring it to 2019.2? I'm sure it won't harm the existing project if you don't turn it on.
But if we can bring it to 2019.2, I can start asking asset developers to fix their assets as soon as 2019.2 releases.
No one will try to adjust their asset until 2019.3 is released and it might take half a year before anyone does anything about it.

Could you please do me a big favor? Can you please bring it to 2019.2. As I said, since it's an optional preview feature, no one will get harmed by it.

Thanks.

 

Is there a scripting API exposed, which can be used to force a domain reload?

 

Yes, we are planning to expose the relevant APIs in 2019.3. At the moment there is undocumented, but public

UnityEditorInternal.InternalEditorUtility.RequestScriptReload

API which forces domain reload next editor tick (but after script compilation if Editor is compiling). We'll expose similar method in a public api space properly.

@Peter77 What is the use case you are thinking about?

 

Thanks for the quick reply!

I thought if we're going to use this feature, it's probably causing some issues with statics for example. In order to quickly find whether this might be related to the missing domain reload, I would expose a menu item "Reload Assemblies".

 

@alexeyzakharov,
You skipped replying on my comment. I really like to ask you once more.
To me, 2019.2 is probably the least exciting release feature-wise in the last a couple of years. This feature can easily make 2019.2 the most exciting release easily. Can you please reconsider to bring it to 2019.2 as optional preview feature? If you can't, what's holding it?
There has been many delays on many features in the past, and can we have something earlier than scheduled at least once?

Thanks.

 

Thanks for trying out the feature! My hope is that is adoption is good, we could ideally make this default and only do domain reload when scripts change (or upon a special request). Then it would also open a path for the partial code patching or other "hot" reload approaches that could speed up the script iteration workflow.

Sorry, I didn't skip or ignored - it is just that I can't simply positively answer your question or promise that I do a backport yet . I've notified our Release Management about the request. Even the feature is optional it adds some risks and is not allowed to be backported to the 2019.2 which is currently in the stabilization phase.

 

Sigh.. sounds like it will push back the adoption at least 4 or 5 months then.
We should've tried to target 2019.2 when we first discussed.

If it's too late, please try to make sure the adoption as easy as possible for Asset developers.
Most of the major assets have to support Instant Play Mode, otherwise, it is no use at all.
This is what I'm worrying about.

Thanks.

 

I normally do not use Beta versions of Unity let alone Alpha versions but in this case i could not resist the temptation.
The workflow time improvement is just amazing! It's a pity it took so long to get this addressed. It works so well i don't want to step back again (Aldo I might regret it later on ;-) ).
For me at least this and the new prefab system are the best upgrades in years!

 

alexeyzakharov
I'm using Unity 2018.3.1f1 and can't update to 2019 anytime soon so is there any patch for Unity 2018.3.1 to fix this issue?

 

I don't think it is possible - we don't backport "features" to the released versions. Maybe try support channels - it should be possible to make a custom Unity build.

 

It's great that you guys are adding ways to sidestep Domain Reload for artists, but obviously 20s reload times for scripters is also quite unbearable. As projects grow, the ability to prototype rapidly, falls right off a cliff.

Is there any plans to actually fix the core issue here, which is extremely slow domain reload? Changing 1 line of code, forcing an entire reload of every object in memory doesn't seem like it should be the desired behavior. Especially not in an era where we have things like Flutter doing hot-reloads on-device in <100ms.

I realize this is likely a massive issue, but this is probably the #1 issue with Unity right now, is it's total lack of ability to scale, and this right here, is at the heart of it. This needs to be #1 on the top of the RoadMap imo. Rolling out 1% initiatives like DOTS, without addressing core iteration time of the engine that effects 99% of us, seems a bit crazy.

The addition of amdefs's seemed like a valiant effort, but the 1-2s overhead for each asmdef totally eclipsed the .3s of compile time you would save. Especially as it turns out, the bulk of the time is not compiling, it's this domain reload.

We really need a solution here where we can still actually prototype game mechanics, in a code base with 5000+ scripts. I get that "Low reload time" doesn't look that sexy on the yearly marketing bullets, but it's everything for us in the trenches.

Some how I'm sitting here in 2020, with a 16 thread Ryzen, changing 1 script file, and waiting 12 seconds for a reload. It's kinda sad

 

Please yes. I must imagine adoption is pretty good now, a yr later? I know 3 mths ago no one on our team knew about it, now it's on by default for all devs.

If patching is possible it would be an absolute game-changer for Unity's ability to build larger titles. Hot-reload is cool but not all that integral, just getting the basic reload time down to <1s would be amazing for productivity.

 

I wish Unity would improve the domain reload after a recompile too.

For the meantime, what I just recently found is that "Edit and Continue" FINALLY works with Unity (using VS 2019 and lastest VSTU).

https://docs.microsoft.com/en-us/visualstudio/debugger/edit-and-continue?view=vs-2019

It seems these highlighted settings are needed:



I use it like this:

• Playing game in Unity
• Find something that doesn't work, set Breakpoint in Visual Studio
  
• Attach Visual Studio Debugger
• Program execution halts at Breakpoint (you probably could also just "break all" with a button)
  
• Change code
• Press Continue
• Continue playing in Unity without domain reload

This is useful to iterate on a small piece of code quickly, as Visual Studio also allows you to set the Program Counter (Set Next Statement). It allows me to just test a specific code block over and over again without having to rely on normal program execution flow.

However, this "Edit and Continue" feature has its limits. It seems to work with simple code changes only for example.

 

Great find, Peter!
I'll be sure to test it with Rider as soon as I can!

 

I'm having a similar problem. 15-20 second compile times with debugger enabled, 8-10 seconds without. This is on a new machine with a 3900x and a small to medium sized project.

I tried profiling to see if I could figure out what's taking so long. 50% of the time is taken by AttachToEntityClonerInjection.Initialize, and way down in the hierarchy below that TypeManager.InitializeAllComponentTypes()

I tried saving my profile information to post, but it won't let me since the frame size is greater than 2GB.

 

Woah, if this works, it could be a great workaround. Looks like it doesn't work in 2019.3. Is this a 2020.1 only feature for now?

 

Hey, guys!

If anyone's still struggling with this, here's what helped us reduce the compile & enter play mode times from 60 seconds to 7 seconds (Unity 2022.2.18).

The Problem

In our project, we use a lot of static classes with lots of pointers to various GameObjects, components, and other assets. The issue is, as the OP pointed out, that when exiting the play mode, Unity serializes all this "static" state, and when entering the play mode, it deserializes it back into memory. And depending on the amount of state, this can mount up to even minutes. Especially our prefab spawner utility was a big contributor to this, as it held pointers to basically every prefab that could be spawned at runtime. And every prefab in turn held pointers to million other things.

The Solution

When the play mode ends, we simply go through every single static class of ours and set every single field on it to default (which for reference types is null). So when Unity goes to see what it needs to serialize to persist it between play modes, there's nothing much to do, since none of our state points to anything anymore.

Of course, doing this by hand would be very time-consuming and error-prone; every time you added a new variable, you'd have to remember to also null it later on.

C# reflection to the rescue! We simply have a list of all static classes, and then a simple loop over their fields does the trick.

Code (CSharp):

1.  
2. #if UNITY_EDITOR
3. private static void clean_up_unity_editor_domain()
4. {
5.     Debug.Log("Cleaning up Unity Editor domain...");
6.  
7.     var types = new Type[]
8.     {
9.         typeof(A),
10.         typeof(B),
11.         typeof(C),
12.     };
13.  
14.     foreach (var type in types)
15.     {
16.         foreach (var field in type.GetFields())
17.         {
18.             // Ignore constants.
19.             if (!field.IsLiteral)
20.             {
21.                 field.SetValue(null, default);
22.             }
23.         }
24.     }
25. }
26. #endif
27.  

At first, we tried to call this function from the editor callback:

Code (CSharp):

1.  
2. EditorApplication.playModeStateChanged += (state) =>
3. {
4.     if (state == PlayModeStateChange.ExitingPlayMode)
5.     {
6.         clean_up_unity_editor_domain();
7.     }
8. };
9.  

But the problem was that even after that callback, Unity still ran one more tick, which of course resulted in a resounding crash, since all the pointers had already been nulled. We could probably solve this by setting a global flag, and then our main tick function would simply return right away, not ticking any other systems and actors. But it felt a little hacky.

Using the "EnteredEditMode" didn't help either, because that apparently gets called after Unity already serializes the state.

So we simply call the function from within the magical OnApplicationQuit callback on our main behavior.

You don't even need to turn the Project Settings -> Editor -> Enter Play Mode Settings -> Reload Domain option off, since there's nothing to reload.

 

I've tried, but it doesn't work. It's our reload time

 

How big is your scene file?

 

about 27KB

 

Ah, then that's not it. Mine had 2 GB.

 

My scene is just a starting scene, there is some manager code out there is basically nothing else, and I also test with an empty scene test, again, the main problem is too many assemblies like my photo.

 

Sounds to be ideal to file a bug report with it.

 

With the recommendation of the project, it is inevitable that the loading time of the assembly will become longer and longer, and now we have 200 assemblies in our project, we can't change anything except to break their dependencies and reduce the abuse of some features. Even then it still takes more than 10 seconds. If you're interested, check out my latest thread

 

I upgarded my project from 2022.3.0 to 2022.3.22.f1

In the 2022.3.0 I got 35 seconds to enter play mode FIRST TIME
after this I got an average 20 seconds entering play time

after the update:

In the 2022.3.22f1 I got 16 seconds to enter play mode FIRST TIME
after this I got an average 15-20 seconds entering play time

BUT

if I edit something on the scene in the new unity (lets say I move a little left a gameObject, and save the scene) I got 01:40 to enter play mode again and again.

If I exit unity and reopen, I got again 15-16 seconds to enter play mode...

What is the issue? How can it be fixed? 100 seconds is a little nightmare for me.

Main link:

https://forum.unity.com/threads/ext...ode-in-the-latest-unity-2022-3-22-f1.1561534/

 

Same for me Unity 2022.3.22f1, after restart it takes 10 times less time to run.