koobas.hobune.stream
Going into Play Mode is slow(er than we'd like)
As our project grows we're experiencing higher and higher overhead on the compile and going-into-play-mode actions. I've been doing some marginal profiles and testing recently to try and narrow down on the culprits. I did manage to get going-into-play-mode time down quite a bit, but I feel there should be more room for improvement.
For reference, it takes me between 7-8 seconds to go into play mode with:
i7 6700k
32GB RAM
M.2 1400MB/s SSD
GTX 970 (largely irrelevant for this I assume)
I also have a laptop, which takes around 10 seconds to go into play mode with:
i7-7700HQ
16GB RAM
SSD
GTX 1070MQ
There are a few things in the profiler that I am not sure I understand. Let's start with a non-deep profile on the laptop: 
This is the first thing that caught my eye when profiling - a big chunk (~5) of the first 9 seconds are spent in ReloadAssembly (1/4th of which is in executing the OnLoadAttribute)
To get more info let's look at the deep profile: 
The first strange thing on this snapshot is that the [Time ms] are not shown in the majority of the stack trace. I assume that's either a limitation of the profiler or a bug. In either case, that's not terribly useful as an absolute metric in deep profile - it's mainly useful to locate the bottleneck. I used the GC Aloc instead, which works in this case.
Looking at this stack trace I also feel a bit worried - you can see CreateDefaultEncoding() opening a FileStream, which eventually loads in all Editor Assemblies. Let's not go into that though - just looking at the bottleneck, it seems that RegisterAssembly() is really what eventually ends up eating a lot of that time (by using some good-old reflection) since it's called 331 times.
This is no surprise, but I am trying to make things run faster, so I ask if anyone has any ideas on how to improve this situation? For instance, why is the profile detecting 2 calls to AssemblyUtilities.Reload()? I put a breakpoint in that method and was able to extract a list of all of our assemblies, a total of 166 - this number seems quite high, this is how they are spread out:
1. 42% - UnityEngine
2. 9% - UnityEditor
3. 49% - Other
Even though the numbers here are pretty high (50% of all of the assemblies are Unity's - about 85 in total), you would think that going-into-play-mode in an empty project will have a similar overhead in the same path - but no, I don't even see that path on the profiler when I run it on one of my minimal demo projects: 
The [Time ms] looks similar, but the cause seems to be different. I can't tell if that's a bug in the profiler showing me the same thing or I am missing something obvious.
Am I going crazy here? I am just trying to find a way to iterate faster while in the editor.
You mean unity re-compile each time you enter play mode?
And you have 166 assembly is quite of weird. Even with new assembly def, you not suppose to have made that many and plugins from unity not suppose to be recompile.
I am not sure, I always suppose unity only have 1 main assembly in Assets folder
It doesn't recompile - On pressing Play, Unity unloads and reloads the Domain (in a separate $$anonymous$$ono instance according to this post - https://forum.unity.com/threads/speeding-up-monomanager-reloadassembly.274133/), which means all C# Assemblies need to get loaded again.
We're barely using assembly defs (only for some of our plugins), which we have quite a few of. A full list of all of our assemblies you can see here: https://forum.unity.com/threads/going-into-play-mode-is-slow-er-than-wed-like.563083/. It is a high number, but if you create a new project and do System.AppDomain.CurrentDomain.GetAssemblies(), you get >100 assemblies from the get-go.
I found another forum about this bugs here:
it seem like this bugs is related to lots of stuff, you should ask unity dev directly for specific help
Try looking into Editor.log
macOS ~/Library/Logs/Unity/Editor.log
Windows C:\Users\username\AppData\Local\Unity\Editor\Editor.log
There might be an error or something strange happening. I found once the Unity Editor uses D://Temp which I already use for other purposes, and it was bogging down creating some data for every file I had in there already (thousands of files). Another problem I had was when my MapMagic was corrupted during a crash. I had to remove each object one by one until it stopped freezing, and the culprit was the MapMagic terrain. Once I recreated it, it was fine. Try creating a brand new scene and test that. Try creating a brand new project and test that.
