Feedback (Case 1161373) 2019.3: Enter playmode time significantly increased

The time the editor requires to enter playmode significantly increased in Unity 2019.3 compared to Unity 4.6.

Reproduce

• Create new project
• Create new scene
• Press Play
• Write down how long it took to enter playmode
• Repeat these steps with Unity 4.6 and Unity 2019.3

Actual
Entering playmode in an empty project takes significantly longer in Unity 2019.3 than in previous Unity releases.

In my test:
Unity 4.6 = 2 seconds
Unity 2019.3 = 5 seconds

Expected
Newer Unity versions should not be slower than older ones.

Note
Please use hardware similar to the PC I used to submit the bug-report with. It probably can't be reproduced on high-end machines.

 

QA replied, unfortunately not really what I was looking for:

 

Thank you for re-opening and further investigating the issue. I'm looking forward for any improvements in this area.

https://issuetracker.unity3d.com/is...nificantly-slower-when-entering-the-play-mode

 

Charles posted a document in which the new Enter PlayMode optimization features are explained as well as what's slow in the current implementation. It's related to this thread and an interesting read, so here is the link for all people who follow this thread:
https://docs.google.com/document/d/1QFMWHG05w7Rj8pe2nz5rbWUm1gj-Pd9M71Uz9dc-dg4/edit#

 

Oh boy, did I find that hilarious... In a big project with loads of assets using the addressables system, entering play mode has taken up to 2 minutes... I had to get a newer PC to get it down to 40s...

I'll try with this feature to see what difference it makes on this project.

Edit: Unless not reloading the domain stops addressables from rebuilding its data, it will not help. Just profiled it, 8 seconds are actually spend entering play mode, 6.5 of which are the domain reload. All of the rest is Addressables.BuildScriptFastMode.BuildData().

Edit Edit: Goodness... just found the culprit for our load times... It's an innocuous line of code in Addressables that does nothing useful on our particular project and costs 28 out of 28.5s of that build step... :-s Gotta check whether that's fixed in newer versions and report a bug if not, this has singlehandedly cost our company weeks of productivity.

 

It was easy in terms of finding the culprit itself in the profiler data, but slightly awkward to actually record.

Had to start recording, press play, wait for half a minute and then stop recording before the relevant frame fell out of the buffer.

This is easier when recording normally, since clicking anywhere in the profiler data pauses play mode. With Record Editor, you need a well aimed click with a solid deadline to stop recording.

Some sort of trigger system for starting and stopping recording would make this a breeze but something as simple as stopping recording when Record Editor is enabled if a frame is selected would be good QoL improvement.

Now for the issue itself, I started a thread in the addressables forum:

https://forum.unity.com/threads/add...ntrycollection-support-massively-slow.701798/

I would have preferred to submit it as a bug but it's an issue of scale, so producing a stand-alone repro would be quite difficult, as it requires a lot of sizeable assets to get to a serious slowdown. Not sure what the workflow could be on that end. Maybe just submitting profiler data but that would be tricky for QA to do much with.

 

This would be extremely nice to have.

 

I heard rumors about Unity is targetting a state change time for entering play mode below 1sec for the 2019.3 tech branch...

 

Can i please cross-reference this thread which has some other people's findings related to this topic: https://forum.unity.com/threads/uni...ower-not-faster-how-to-compile-faster.511199/

 

Could you please let me know in what Unity version the fix landed? The original bug-report is closed and the public issue tracker item is marked as "fixed in 2019.3":
https://issuetracker.unity3d.com/is...nificantly-slower-when-entering-the-play-mode

What beta should I use to re-test the fix?

 

Thanks for the quick reply. I'm going to take a look at it with b12, once released though, and report the results here. Can hardly wait to see how it improved!

 

UI BUG DESCRIPTION
Unity 2019.2.12f1 always take 5sec to start in Play mode.

Environment
Hardware Device: i7 2600k, GPU GTX 1080Ti, 24Gb Ram,
Hardware Device: i5 9600k, GPU GTX 1080Ti, 32Gb Ram,
OS: Windows 10 64bit ()

Severity
Customer Impact: normal bug (always)

Note
4 min per day per user. If 100.000 users press 50 times Play button per day per 5sec = 25.000.000 sec = 290 days or one year of human life lost waiting for Unity to start per day.

@alexeyzakharov @LeonhardP Hello World: As an example to understand how long

 

I've just tested 2019.3.0b11 and it's not fixed in my opinion. Entering PlayMode in an empty scene with b11 takes 4s vs 2s in Unity 4.6, so it's still twice as slow.

Spoiler: Profiler

PS: As I wrote earlier, please use hardware similar to the one I submitted the bug-report with. You most likely can't reproduce this on higher end machines.

 

Hi Peter. Many thanks for your sterling efforts in profilng and documenting the decline in editor performance over time. This is very valuable imho. Have you had a chance to try out the newer "enter playmode without domain reload" functions yet? Do these offer any improvement in your view? Thanks!

 

I've tested 2019.3.0f1 which continues to be significantly slower in "EnterPlayMode" than earlier Unity releases as written in the first post.

I've updated the bug-report Case 1161373 with a profiler capture. I hope it helps to solve the problem.

Spoiler: Profiler Screenshot

 

Yep, it's a nice improvement and enters playmode pretty much instantly in an empty project.

The downside for me is that it requires to write your code in a way that this system can handle. For existing projects, it's often not as simple to support the new instant playmode. That's why I would like to see at least the performance of earlier Unity releases, so I don't have to rewrite existing projects to have acceptable timings.

For new projects, I believe it's great if you use it right from the start. Then you can write all the code right from the beginning with instant playmode in mind. So it's definitely an appreciated feature, just not for existing projects in my case.

 

Thanks Peter, very useful feedback as always!

 

I've tested 2019.3.0f3 which continues to be significantly slower in "EnterPlayMode" than earlier Unity releases as written in the first post.

Spoiler: Profiler Screenshot

 

@Unity_Javier sent me an early build of 2019.3.0f4, which comes with various performance improvements. The editor does feel faster than earlier Unity 2019.3 releases, but there are still a few things that should get ironed out.

Unfortunately, "EnterPlayMode" (in a new/empty project) didn't improve in this version compared to the previous beta release. It still takes significantly longer than Unity 4.6.

Spoiler

 

I wanted to add that this isn't just a 3 second time increase. If you put it into HDRP mode and add a scene with only a couple thousand lines of code, it takes 18-33s to enter playmode (usually 22-25 with no c# script changes).

 

"without domain reload"
Please make a video tutorial in Youtube.

 

• But trigger more hiding bugs
• There are spelling errors and difficult to understand when to use it:https://docs.unity3d.com/2020.1/Documentation/Manual/DomainReloading.html
• [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)] is to long consider: [Reset]
• But looks complex. Must be for stupid prove. Probably I will fail to understand when to add the attribute.
• So use the Right-click button to trigger this special Play Mode
  Right-click = Play Mode without domain reload