Awful Editor Game Start Time

Is it me, or after moving from 2019 to 2020, start time for playing has increased dramatically?

I know there is experimental play mode which I can disable domain reload and all that, but honestly, these options are rarely used, because most of the time you have changed either scene or script itself, or both. And having this option in the project setting is worst, because you have to have this window open to change the option so often.

And I am sure, updating project from using 2017 to 2019 then 2020, it keeps getting slower to start playing. And I am not saying that the scene is a lot heavier to load than before. The reloading of “whatever” seems to take really longer than before. And everyone I am working with says the same thing.

Is this something that will be improved over alpha, beta stages? or will it just get slower and slower?

Or is it just me that feels this way? (am I crazy? going mad? )

2 Likes

You still use same packages on 2020? DOTS and burst, HDRP etc do add a bit to the play in editor start times.

I do use dots and burst. But I used to use that on 2017 and 2019. But on 2020 it is noticeably slower.

I once found game start time in editor go from like 5s up to 20s+ over the course of several days and hundreds of starts, editor restarts, system restarts etc it just kept getting worse. Nothing significant enough had changed to warrant such a difference. In my case (at least), there seems to be a connection between this problem and the Library folder. After deleting this folder and restarting Unity Editor (which will take a while the first time after due to reimporting everything etc.) it dropped from like 20s down to 3-4s. Make sure to close Unity Editor first. Also make a full backup of the project in question before doing this just in case - the only things I’ve noticed as “issues” after this are that the build target platform isn’t always what it was before (just need to click “switch platform” back to previous one in build settings), and the previous Scene that was open doesn’t open automatically again from the project link in Unity Hub (just need to click File->Open Scene then the next time it does). The first thing I do now when things get sluggish is delete this folder - works every time.

4 Likes

Interesting… and I wonder why deleting Library folder to retrigger import helps… is this really true?

Mine seems to mention sprite atlas packing when I hit run when the loading dialogue comes up, does it several times a day too. Backported to 2020.1 beta and it doesn’t happen there.

Wild guess… is Project Settings->Editor->Sprite Packer->Mode set to Always ?

That’s probably a setting which is on by default in 2020.2 alpha but in 2020.1 beta it’s actually not there! Makes sense why 2020.1 beta works fine and 2020.2 always does it at the start of play mode.

My guess and guts tells me that it is this asset databse version 2 that is causing some significant reloading time… this is by looking at the start play dialogue popoup displaying what it is doing… also that is one thing that is different than from say Unity 2017…

It would be great if you could supply us with a reproducible that shows decreased (enter playmode) performance once updated to a newer version. In the meantime, I’ve forwarded the thread to the team.

Yeah, I can understand why you would like to get a repro report… But you normally ( and it was for me ) to notice and really feel like so after using it sometime after upgrading, and going back version to make it work again just takes too much time off my development plan. I just wish I had some backup, but then it isn’t going to be a fair comparison again.

I just feel like the game should not take like 13-14 seconds to enter playmode… I had way more complicated game running with 5.x 2017.x version of Unity and they don’t take as long as the one I am developing right now. And I am running it with much much more faster computer than before… 2017 era.

4 Likes

It’s not you. Time to enter playmode from a script change has increased quite a bit since 2019.3.

This is probably the best thread covering the issue: https://discussions.unity.com/t/746461

Some people including myself got the old enter playmode from script change times back by switching back to asset database v1 (this was on an older version of the editor from around the times mentioned in that thread not the latest beta/alpha).

I then had to go back to v2 anyway because the latest DOTs requires it.

It sounds like Unity aren’t going to do anything about it unfortunately. I skimmed the thread again to revive my memory. Someone opened an issue but it got closed because QA couldn’t reproduce enough of a slowdown or something.

3 Likes

Yeah, like I said too, I highly suspect it has a lot to do with assetdatabase v2… I bet my 2cents on it.

Thought I was the only one that noticed this. I’m on 2020.1.0b15. When I deleted the library folder everything was actually pretty fast and slick. However after about an hour or two of work the project was taking 10+ seconds to enter playmode, and had like 3 - 5 minute build times, where before it was only a minute build time. Pretty much everything was slower and sluggish. I have a decently big project size but nothing crazy so this is annoying and actually a threat to productivity.

1 Like

Ok, so after upgrading to 2020.2a18 and then upgrading to the latest addressable has improved game start time! After reading the update note on Addressable, there was mention about fixing stuff that affecting the start time indeed!. So in my case it was partially due to bug (or issue) in Addressable. I still feel it can be improved… the release note on a18 version indicates that there is known issue for AssetBundle Loading is slower, and Addressable is based on AssetBundle so hoping to see even more “improvements”

3 Likes

Agree to the bundle loading times being an issue. I switched from resource folder to addressables and loading became significantly slower.

I’ve noticed this but when moving from 2018 to 2019.4. Ridiculously long start times, like 2-3 minutes

I have project which started from 2017, migrated all the way to 2020.2 (2017, 2018, 2019 2020.1, 2020.2) in relatively short period of time. During this transition, there was not that much added in terms of assets and scripts but had many third party assets already and took long time to make sure they work on each versions so going back to 2017 to test it again is impossible now. My starting time gradually seems to have increased from anything from 2-3 sec to now almost 15 seconds.

My current guess is that it has to do with upgrading package assets as per migration requirements and also asset database v2.

Only “improvements” I got was from updating to the latest Addressable which fixed some delay in starting time, (like 2 seconds) but it also has mention that AssetBundle right now has some issue as well.

So my suspicion is :

  1. Texture Atlas V2
  2. Addressable
  3. AssetBundle
  4. Package assets (all from Unity ones)
  5. Asset Database V2
  6. New Editor UI “improvements” ( the slim font and all that came out a while ago )
  7. Maybe .Net version? from 2.0 Subset to 3.5 to 4.0 to Core 2.0 …
  8. The new debug editor mode. ( So Visual Studio can attach to Editor )
2 Likes

Maybe this can prove your suspicions!

1 Like

Yep, the Editor Interation Profiler was practically made for this. However you could also just generally use the Profiler, targeting the Editor. Ideally running as a Windows → Analysis-> Profiler (Standalone Process) to avoid the profiler window itself contributing to the time to enter Playmode, (or, while the Profiler window is closed, using the F9 shortcut to start profiling before entering Playmode and stopping again after).

If you still have a revision in version control that works on previous versions, you could profile that two and compare the data using the Profile Analyzer.

Finally, if you find that the performance regressed due to something outside of your project, please file a bug report. Any data you gathered through profiling would be valuable in the report (and can be compressed significantly by zipping btw). Speeding up the Editor Iteration times is something we’re looking to improve in different ways and we certainly don’t want to regress there.