since I had 4.6.9 reinstalled and tested editor regression I ran a quick and non scientific test of how much slower script reloading is. It is 3x slower compared to 4.6.9
I brought this up a while ago too:
https://discussions.unity.com/t/746461
You can use OBS (it’s free) for screen capture without watermarks. Also you can control your audio right there, IDK but maybe your reaction was the part of the comparison…
I’ve sent in a profile of my tiny project, with asmdefs, that takes several seconds both to compile script changes and to enter play mode. Case 1212215.
Edit: made another one for another thread. Case 1213483.
1 Like
Things are better with 2019.3.0f5 but it is not completely gone yet.
Hi @spiderspy ,
Thanks for the reply and sorry for the long responding time (I was on vacation and somehow missed your reply). Unfortunately I can’t say much myself on what is UnityEditor.Rendering.DebugWindow as I am a QA from a completely different area, but I asked responsible devs and this is what I got:
" The DebugWindow is a helper window used to check various settings of the scene, it is available in HDRP code and could be disabled but i doubt this is the source of their issue. If user is on 2019.3 they could try avoiding reloading domain assembly (Project Settings > Editor). I am not sure this is HDRP specific though based on the thread. "
Not much, but if you have some specific questions - don’t hesitate to ask 
What I can add is that devs looked into that piece of code and found some potential places for improvements (but not something that could explain behavior you experience though), so lets hope that code will be optimized at least
Thanks again
The only thing preventing me from using the new scene reload settings is Unity. The new input system dies unless you do a classic full reload every time you enter Play mode.
1 Like
This is a known limitation of the new Input System at the moment. We’ll add a note about this to the docs. Adding support for this is on the backlog.
1 Like
@Unity_Javier @LeonhardP
I tried again asset pipeline v2 after some months hoping the slow down would have been fixed but they are still there.
I noticed something which could affect many here.
With v2 now whenever I change a script, all the scripts onValidate methods get called, even if these script aren’t in the scene.
Why is that?
With V1 this didn’t happen. I am using the latest LTS as of today.
Also is there a way to know on the onValidate method if we are being called normally or in some special case like builds(this is also quite new, old Unity versions wasn’t doing this) or compilation?
1 Like
For detecting whether it’s during a build, you could use BuildPipeline.isBuildingPlayer:
https://docs.unity3d.com/ScriptReference/BuildPipeline-isBuildingPlayer.html
It doesn’t seem to work inside OnValidate, cannot build the player with that method since it doesn’t exist in that context.
Anyway I confirm that assets pipeline v2 is at least 10 times slower than v1, rolling back immediately again.
Even after a simple build error it did an additional refresh of probably the whole project for another 20 seconds, while with v1 I can work with the project immediately. I think it is nowhere near v1 at the moment, maybe with huge projects and cache server it makes sense, but not for medium projects where the additional overhead is way too much.
EDIT
Ok rolled back. Switching from v1 to v2 took me more than 1 hour.
Switching from v2 to v1, few seconds…
That’s odd, I don’t see why it shouldn’t work. You did put the code inside an #if UNITY_EDITOR #endif block, right?
I didn’t think of it, I thought it would just ignore the code on build then.
I just tried and it works… does this mean the code is built two times for every build? One with the UNITY_EDITOR macro and one without? Pretty strange.
Hey @00christian00 ,
This is actually a regression with how we’re managing loaded objects.
For example, if you restart your editor with V2 and no prefabs are loaded (i.e. no scene with Prefabs open, and you haven’t clicked any on the project browser), then you won’t get calls to OnValidate, but if the Prefab does get loaded, then calls to OnValidate will happen.
We’re working on a fix to this right now and I hope to be able to get it backported to 2019.4 relatively soon.
Thanks for bringing this issue up, it is a pretty bad regression.
5 Likes
@Unity_Javier Are you still working on this issue with slow load times in general?
It seems from my testing, more than compile times, the issue is really one of file count.Once you get up to 10,000 files plus, your reload times are going to be >10s, and it really doesn’t matter what you do…
I wonder if we can go back to first principles on this: We need a scripting layer, that has access to everything csharp-firstpass has, which can be re-compiled quickly. Without triggering a full-scan of project.
Is this really unachievable?
Is there not some alternate angle we can approach this from to just make it happen?
- Maybe some new dll that sits on top of c-sharp-firstpass, meant specifically for “hot” script files? We could make /Scripts a special folder (optionally of course), that gets it’s own top-level DLL and special watch rules.
- Make /Plugins a ‘safe space’ for cold asset files. Give us some ability to manually reload /Plugins, so we can have some area of our project that can be ignored during 99% of our domain reloads. Then we can use everything outside of plugins as our “hot” asssets, and plugins can be all the cold stuff.
Any other thoughts?
The fundamental issue here is that projects have hot and cold files, and Unity does not acknowledge this reality. It lumps them all together, making reloads extremely wasteful. When 98% of your changes, are made to <5% of the files, we should not be re-loading 100% of the files on each line of code change.
We need in some way, to de-couple script rebuilds, and asset scanning.
2 Likes
I believe they addressed this with the new “Directory Monitoring” option, which was introduced in 2020.2 maybe?
Very interesting! I was just reading about this in the 2020.1 release notes.
Just upgraded and it does seem to have shaved off about 2-3 seconds! I’m at about 7 seconds now to reload, with about 10,000 files in the project and 3000 scripts (73 outside of /plugins). As long as it stays around here we’re in a pretty good place!
Still would be really nice to have this scripts-prepass.dll that was like 1s compile time…
2 Likes
Hey!
We are definitely looking at slow editor iteration (I guess this also means load times) issues. We’ve created a sticky post here: Long waiting times in the Editor - Slow asset refresh when modifying any script and we’ll be updating it with improvements to the Editor that we find are slowing down everyone’s workflow of:
- Modify Script
- Tab into Unity
- Wait for Editor to become responsive again.
Also, we have a Blog Post available that talks about other ways to inspect where time is being spent: Tips for working more effectively with the Asset Database
With regard to your suggestions, I can ask someone from the Scripting team to shed some light into the upcoming improvements coming up in the near future with regard to just this, but I think some of the ideas you’ve mentioned might conceptually overlap with some of the work that has been done by the Scripting team.
1 Like
Awesome, thx for the info, and so glad you guys are still on this. By far the #1 issue in my books.
1 Like
I’m suffering with this issue at the moment … I set up assembly definition files to try to fix it and that had no effect other than to reduce compile times slightly. The delay all seems to be in domain reload. It also seems to coincide with us starting to use addressables in our project.
I profiled the editor and it shows this …
Note the giant GC alloc for around 3GB. I suspect this might be it reloading all the textures we are using in our addressables database - this is just a guess at this stage. Anyone have any thoughts on this as waiting an entire minute for every compile and reload is hitting our productivity very hard.