We are seeing extremely long loading times with a 2017.2.0p1 windows standalone build, before the splash comes up.
In the logs, there is this candidate:
Begin MonoManager ReloadAssembly
Completed reload, in 75.748 seconds
This has been observed on four different machines (all with Windows 10). Restarting the software several times brings this down to <1s. Rebooting the PC and this again takes 70 - 100(!!!) seconds.
When starting the software, the Windows hourglass pops up for like 2s, then disappears. For a full minute plus it looks like nothing happens (which is where any user would start the software again. and again). Then it comes up.
I haven’t seen anything in later patches and searching for reloadassembly brings up a ton of in-editor stuff. Any pointers/ideas would be highly appreciated, this is obviously a very bad situation.
Yes. The profiler finds the game at start but freezes for the aforementioned time frame (essentially before showing anything). When it starts profiling, it instantiates the first scene and that’s pretty optimized, taking like 1.5 seconds, looks fine to me.
Just to make this clear: This 70-100 second delay happens before(!) the game window with the splash even comes up.
I double click the game executable.
Change into Unity.
Find the game in the profiler drop-down, select it. It seems to start recording but nothing moves.
It remains like that for a minute plus.
It suddenly shows messages in the console bar, the game shows in the task bar, the splash screen comes up, the profiler starts profiling. Again: After one minute of nothing.
This waiting time is in sync with the time shown in the output.txt under “- Completed reload, in xxx seconds”.
It doesn’t happen all the time. Maybe 8 out of 10 times after reboot. On several machines. Too often. I’m at a loss of what happens in the standalone build in Begin MonoManager ReloadAssembly and how we could profile that?
When I look at a sample between starting the executable and showing the splash screen, I see essentially only tcpip activity, coming from the Unity dll. Not much, like 25 events in a 5s window. But continuously through the whole one minute time before anything visible comes up, which is being logged as ReloadAssembly in the log file.
Any thoughts what this could be?
Is my assumption correct that it most likely is not “our” network stuff, which is in “Start”. Is anything we’d have in Start or Awake being executed before the (custom, not Unity) splash screen shows?
I can think of Photon or Google Analytics being a candidate. Have you heard of this before? I don’t think we are using Unity Analytics, but are you pinging your servers before an app starts?
Thanks for your help, I’m sure this is going to help anybody running into this ugly behavior
What kind of hard drive are you running your game on? The majority (64.95 seconds!) of the time is spent waiting for Windows Defender to scan the files engine needs to load:
That either suggests too aggressive Windows Defender settings or extremely slow hard drives. Or something totally different - I am not too familiar with how it works (other than reading files seems to automatically initiate the scan - that much I can see from the trace).
Could you try disabling windows defender for a test to see if that solves startup time issues?
It’s a gaming laptop, harddrive shouldn’t be extremely slow.
The weird thing is we saw that with other machines. I don’t dabble with Windows Defender but with the constant Microsoft updates I wonder if they did. We will all be in a world of pain if that’s the case
I’ll check the machine, do those tests and let you know! Big thanks
But I tried to explore the question if something was wrong with the harddisk. And found something interesting.
My laptop has the typical SDD - HDD combo. The SSD is mainly holding Unity projects, Windows and old Nvidia drivers (sigh).
So as a first step I copied the standalone build from the HDD to the SDD. And that took extremely long. It started out ok, then suddenly the transfer rate dropped to like 100 kb/s for a lot of small files and it took a long time.
The standalone started in 2 seconds from the SDD, consistently, after reboots, etc.
Copying the standalone back to the HDD, and it started from there in 2 seconds, consistently.
Any subsequent copy process was fast.
A chkdsk on the HDD didn’t reveal any problems. I’m using it daily and it is as fast as you’d imagine.
I can only speculate at this point. A weird combination of bad sectors, defender having trouble reading files, something else? Leading to a wait time of over 1min? Fixed by the copy process?
If we had not seen that happening consistently on another machine, I wouldn’t have posted. I don’t have access to that computer anymore or I’d try if we’d see similar behavior.
Fwiw: The files were installed from Unity Cloud Build zip files.
We are going to watch this going forward and if someone else is seeing this behavior, I hope they find some valuable pointers in this thread to explore, thanks Tautvydas!
Hello. I reproduced the same phenomenon with a Unity 2020.3.18 Windows Builded exe.
Occasionally, 60 seconds, etc. are recorded in Completed reload, in x seconds.
However, it only happens once in a few times in my environment and I have not yet been able to get a profile. (Once it happens, it doesn’t seem to happen right after.)
Do you have any tips?
You could keep Windows Performance Recorder open at all times, and when you notice it is happening, just hit record. It’s fine to miss half of it - you’ll still capture some data.
Seriously, I’m sorry.
I tried Windows Performance Recorder and Windows Defender really took 60 seconds.
Even after 5 years, Windows Defender has not evolved.
Thanks reply.
Figures. Unfortunately you cannot do much about it. At the same time, this shouldn’t really be an issue in a released game as Windows Defender will only scan files once. It is pretty awful for development though, because every time you make a build, it thinks those files need to be rescanned.
