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? )
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.
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.
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.
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.
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.
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”
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 :
Texture Atlas V2
Addressable
AssetBundle
Package assets (all from Unity ones)
Asset Database V2
New Editor UI “improvements” ( the slim font and all that came out a while ago )
Maybe .Net version? from 2.0 Subset to 3.5 to 4.0 to Core 2.0 …
The new debug editor mode. ( So Visual Studio can attach to Editor )
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.