We’re also further investigating this issue.
For now there’s no issue tracker link that I could provide.
But the issue is reopened and QA is taking a deeper look into it.
Thanks again for your time reporting issues that you encounter!
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:
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:
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.
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!
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.
@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.
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!
