I must say, this has made a VERY surprising difference. Just by disabling Auto Refresh and Directory Monitoring, when I make a change to a script and alt-tab to unity and hit Ctrl-R its at least 10-15 seconds faster. Plus it’s eliminated all those times where I didn’t need care about a recompile and wasted my time waiting for the editor to respond again.
5 Likes
This issue “Scripting: Increased Script Assembly reload time 1323490” was referenced in the past 5 LTS releases for 2020.3.x, other than the last one, as a “known issue”. In the latest release, 2020.3.21f1, there’s no mention of it.
Is it now fixed, or just missing from the known issues list?
Thanks!
1 Like
Theres a better way, you can actually screw with the play mode states in editor so that when you press play, you can run custom code before it enters play mode. The ninjas approach is good too, its pretty much the snippet here but theirs runs later in the flow (mine runs as if it just ran before you pressed play)
2 Likes
FYI. I converted to 2021.2. I’m not seeing any meaningful changes in editor iteration time. I understand the majority of improvements are slated for 2022.1. I’m looking forward to it.
While doing some compile tests for the new M1 Max , I also had a chance to compare the domain reload times for 2020.3.21 vs 2021.2, on my intel i9.
Sadly, it looks like 2021.2 has regressed further in performance. On the same machine, same project etc, it is approximately 10% slower than 2020.3.
The Compile times are superduper fast now, but the Assembly Reload, which is the true cause of slow developer iteration time, has regressed.
18 Likes
2021.2 is measurably worse than 2021.1.x. From a deep iteration profile I am seeing duplicated effort which manifests randomly.
- AssetDatabase.Refresh occurs twice. Once in AssetImport and again on AssemblyReload.
- Application.UpdateScene occurs twice. Again, once in AssetImport and again in AssemblyReload.
I don’t always see this duplication. But when it happens the iteration hit is 35s instead of the ‘normal’ 12s (see above). I am including exported profiler data as well as a screenshots documenting the same.
I can’t stress enough how damaging this is to productivity and workflows. All hands on deck, fire on the bridge.
Screenshot:
Export:
https://tonstad.blob.core.windows.net/media/EditorIterationData_2022.2.0.zip (6MB, .CSV and .JSON).
Support Ticket:
FogBugz 1376641
18 Likes
I noticed the exact same thing in my own projects.
I’m pretty sure this definitely has something to do with Visual Studio (or more precisely the Visual Studio Editor package). I’ve tried doing edits in Notepad++ and Rider and both of them don’t result in that function getting called twice at least for me.
On the bright side, it seems that 2021.2 makes building for both Windows and Android a lot faster without touching any settings. Clean builds took 10-15% less time compared to 2021.1, 2020 LTS, and 2019 LTS.
We’re now on 2021.2.0f1 and we can say this new version has made the “Fast Enter Play” mode twice slower. In 2021.1 we were able to enter play mode 4 seconds after hitting the button. We now have to wait for 9 seconds.
This is a problem.
7 Likes
Huge problem. The no. 1 reason many of us keep updating Unity is to get faster compilation and play mode times (which is always touted as being improved), yet when I measure the results, it’s always the exact opposite…
It’s good that Unity finally acknowledge this bizarre take on “progress” - now please devout all possible resources to rectify this travesty…
7 Likes
Has anyone tried this to speed up the script compilation time? Unity - Manual: Assembly definitions
Oh, yes. Been doing that since 3 years - don’t expect much… While it certainly does speed up compile times in your code editor, as soon as you switch back to Unity it seems to recompile everything as if you didn’t have the asmd-files in the first place. Making your with a net win a solid 0.
6 Likes
Just updated to 2021.2.0f1 and sometimes getting error when changing the code too often in Visual Studio:
Library\ScriptAssemblies\Assembly-CSharp.pdb: Copying the file failed: The process cannot access the file because it is being used by another process.
This is on top of 20 seconds of Reload Assemblies message. I already made a bug report Case 1376324.
2 Likes
This does improve compile time, but it increases the amount of assemblies to reload, which would increase the domain reload time instead. This is the issue at the moment, domain reloads not the compile times.
2 Likes
Isn’t the underlying problem here that no one at Unity use the editor themselves? Even on toy projects, it is immediately obvious how painful the turn-around time is.
11 Likes
I’m always a bit surprised how game developers, of all people, can lack the basic imagination for how impossibly difficult managing a project at the scale of Unity has to be. Sure, blame them for not delivering! Call them out for their failed strategic decisions! But suggesting no one at Unity is using their own product or doesn’t take user feedback very seriously is just lazy.
9 Likes
I think you might be missing their point. I doubt they were suggesting nobody at Unity uses Unity, but rather that Unity employees might not be living with the product for day-to-day substantial game development.
And I think this is true — as far as I know, Unity does not own or operate a game studio, so presumably there aren’t Unity employees whose full-time job is to build large, multi-month or multi-year projects in Unity. The problem discussed in this thread is one that would only tend to weigh on someone if they’re building larger games, iterating dozens (or hundreds) of times a day, every day.
This is not true of, say, Unreal Engine (which has plenty of its own flaws to be clear!) but I’d wager the feedback loops at Epic are tighter than Unity, since Epic has hundreds of people on staff using the engine to build large-scale shipping games (Fortnite, Gears of War, etc), in addition to lots of folks working on the engine.
12 Likes
I feel we have to be honest about the fact that when so many of us have been getting more and more frustrated for several years and Unity not even noticing, then there’s a pretty unhealthy disconnect between the makers and the users of the tool.
Paying closer attention to the forums might help. Having turnaround times a clearer (and measured) priority might help. Dog-fooding the editor would definitely help - hard not to notice how bad things have gotten if you’re an actual user of this thing.
4 Likes
For us sometimes the reload times go over 20 seconds. I checked the logs and it’s CreateAndSetChildDomain (16126ms). It doesn’t have any child items and everything else was normal. Hope this helps.
2 Likes
I am not suggesting they don’t take user feedback seriously. I am also not suggesting that they don’t open the editor during development to test changes that are made. My point was that they don’t use the editor for actual development. Dogfooding, in other words.
Let me quote the beginning of this thread:
Earlier this year, many users have reported increased waiting times (from 2s previously to 4s/6s) when changing one C# script + waiting for a domain reload on a simple Core 3D template or when entering Play Mode, in some 2020.x versions and newer 2021.x versions.
Clearly this was caught by the users and not Unity themselves, or they didn’t consider it important enough to report internally or in beta. Again, this thread suggests that the problem is considered important but it was not caught internally.
My point stands: If Unity was using the editor themselves for real development, this would have been fixed because the impact on productivity is immediately noticeable.
Edit: I will grant you that it is entire possible that product owners don’t take internal feedback seriously.
7 Likes
See the recent update for both 2019 and 2020 LTS versions which broke shader compilation when making builds using batch mode with -nographics (rendering most CI setups useless) as a good example of lack of proper dog fooding.
1 Like