Official Improving iteration time on C# script changes

Is this fix about issue #1143037, where static batching n scenes on entering play mode in the editor actually batches 1+2+...+n scenes? That cost us ~60 seconds on enter play mode back when I reported it in 2019, but the bug report got "Our developers are currently working on other projects that are of a bit higher priority than this case."

 

I just want to chime in to say that this type of communication is very valuable and appreciated. Thank you!

 

I agree with joNax. It's good to know Unity is aware of this issue, is taking it seriously, and is actively working on getting this fixed. Good job!

 

Thank you, xoofx.

Including the fixes described above -- is parity with 2019.x achieved? I don't think the task force should rest until iteration returns to sub second.

 

Thank you for communicating about this important issue, xoovf.

Now I really hope management doesn't pull you guys away from that and put you on other "priorities". Fingers crossed.

 

I really appreciate the update, thank you xoovf and team.
This is such an important issue to me, it makes me feel a lot better having this acknowledgement.

Please let us know how the community can help. Whether it be profiling data or even uploading whole projects, if that helps. I know I'd be happy to provide, if it proves useful.

 

I appreciate this update!

I wanted to focus on briefly mentioned detail in particular: as much as possible, it would indeed be great if all fixes are ported to 2020 LTS. I understand that this is caused by a multitude of factors, some more recent then others. But for parts that originate from changes in Unity 2020, it would be good to rectify them for 2020 LTS - not every project has ability to jump to 2021 and getting stuck with permanently slowed down iteration time wouldn't be ideal.

 

Agree with @stonstad and got surprised by that answer... sorta asumed the final objective was to return to previous iteration times, independently of how many features are added to the engine. If we are going to be losing seconds to every thingie that Unity introduces, the whole thing would be unsustainable in a matter of months

 

Thanks for the updates

We are currently at 2019LTS, and we want to migrate our projects to 2021 LTS (as soon as it is available)
Would it be possible to have these optimizations landing on the 2021 LTS tech cycle?

 

Is it possible to turn off the auto compiling, and manually trigger it when I want to? after I hit save in VS unity turns unresponsive for up to 10 secs, and only then does the green percentage bar appear, for another 5-6.

 

If I understand you correctly, then you can do that from Edit -> Preferences -> General and turn off Auto Refresh and Directory Monitoring. When you need Unity to compile/refresh, hit CTRL+R. Just know that if you forget to hit CTRL+R then you won't have the newest changes from your script in Unity. I ended up creating a new button in the editor that I use instead of play mode that refreshes first so I reduce the chance of going into playmode with old scripts.

 

Try to compare it to making a script change in Notepad. This could be VS acting up - it often does.

 

That's a brilliant work-around! Would you mind posting your button source on a Gist?

 

Thanks , it's nothing fancy, and required me to remap some muscle memory for a bit, but otherwise, it works well enough for me at least.
Sure, you can find it here: https://github.com/Per-Morten/UnityUtilities/blob/main/RefreshAndPlayButton.cs

 

Reading this thread has alone regrown some hairs on my head. Thank you @xoofx I know you personally push for a lot of boring/subtle but ultra important improvements behind the scenes!

What would be the ideal way to present additional problem areas for this? For example, our project has become extremely laggy with the in-editor experience over the past couple of years. Here is a quick example of me interacting with a couple of drag-n-drop elements:

We've done our best to debug and isolate the root cause but its been too hard without deeper metrics into Unity Editor.

 

If you don't want to learn a new button and an extra window, just put it in a file in an Editor folder:

Code (CSharp):

1. using UnityEditor;
2. using UnityEngine;
3.  
4. public static class EnterPlayMode
5. {
6.     [RuntimeInitializeOnLoadMethod]
7.     private static void Init()
8.     {
9.         EditorApplication.playModeStateChanged += OnEnterPlayMode;
10.     }
11.  
12.     private static void OnEnterPlayMode(PlayModeStateChange obj)
13.     {
14.         if (obj == PlayModeStateChange.ExitingEditMode) AssetDatabase.Refresh(ImportAssetOptions.Default);
15.     }
16. }
17.  

Note for people who read this out of context: read the thread. This editor script should only be used when you turn off the directory monitoring and auto refresh. If you don't have problems with your code editor and Unity editor working together by default, it isn't for you, probably.

 

Ok, that's way better, thanks

 

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.

 

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!

 

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)

 

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.

 

@xoofx

2021.2 is measurably worse than 2021.1.x. From a deep iteration profile I am seeing duplicated effort which manifests randomly.

1) AssetDatabase.Refresh occurs twice. Once in AssetImport and again on AssemblyReload.
2) 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

 

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.

 

@xoofx

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.

 

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...

 

Has anyone tried this to speed up the script compilation time? https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

You're wrong.

 

If he/she is wrong, how come they admittedly didn't notice what they now had to assign a task force to fix?

 

Spoiler: We're fairly off-topic

This is a complex question.

First of all, working on a real game doesn't provide what you are looking for. Game development doesn't happen on this way. If you start a project, you do not (well, you should not) upgrade your editor (and your engine and tooling, etc) under it unless in exceptional circumstances. Which means if Unity made a game, they wouldn't use the beta version of the editor. This is why this argument is incredibly silly.
Second (and it ties back to the first point), their clients (where most Unity employee using Unity Editor as a game/film/etc development tool) are professional developers, usually studios. Professional developers don't use unreleased or freshly released tools unless it's an exceptional emergency.
Third, you're assuming that this few dozen forum developers are the majority of users, but they/you aren't. For the majority of users these problems usually simply don't exist. Maybe some special hardware cases, interference with other software/hardware, using HDD and not keeping it defragged, and so on, there can be many different reasons that some people see a problem, but others don't.
The point is, Unity has millions of editors installed on millions of people's devices, and they don't see millions of complaints.
And finally, now had to assign a task force because they found some problems, which may be fixable by them counting with the cases you people provide(d). This is why submitting bug reports is crucial. You can't assume that they know about it, because today's computers are incredibly complex machines, you maybe the one, who sees the problem. Or maybe just member of a small group. If you don't report it, it can stay and bother you because the majority just can't see it. And I deliberately used the "you" here, because for example I experienced literarily none of these issues (although I may just got lucky with one or two, it works both ways).

Edit, I forgot to add: Unity also is working on extensive demos all the time. Like they do this forever. All those teams are also using Unity on a day to day basis. Adam demo, BotD, Blacksmith, Island demo, etc don't appear out of thin air. People are spending time in the editor realizing those.

Disclaimer: I am a software engineer for 23 years now for a living and tinkering with software for 32 years. I was member of many teams who were responsible for user-facing software. I saw this from the other side of the table many times.

 

It doesn't matter if they use Unity or not. Employees of Unity using the engine doesn't mean their manager will tell them to focus on making the editor faster and nicer to use.

And Unity (the company), clearly did not have editor user experience as a priority for many years and now they (and we) are paying the price. One year of placing editor user experience higher on the priority list isn't enough to fix that (even if we take them at their word).

And dogfooding doesn't really matter. I'm pretty sure many employees know the issues. Whether they are allowed to work on them is another thing.

I think the only effective form of dogfooding would be if we took all upper management and made them make a good indie game using Unity (the goal would be to release a game on steam for 15$ and it would have to get reviewed by prominent press and get at least a 7/10 overall), and somehow make their livelihood dependent on whether they succeed at that. You could even make a reality show out of it. I would so watch that.

I'm pretty sure then priorities would change towards making Unity good to use, and not just look like it is good to use.

 

Sorry Tim, you can't use Fortnite to battle test Unreal Engine 5, even though you announced you would, because Lurking-Ninja said so.

And there is plenty for Unity to discover how broken or ill contrived their engine is by trying to get a large game working in the LTS or Tech stream. There's no excuses here for me. I understand that it's probably never going to happen, but it doesn't mean the company shouldn't act if thought they were working on one with much more focus on optimisation.

 

I also get this, and I have to restart Unity when it happens to continue to work. So frustrating.

 

My solution now is to add a new line and save it until it shows the "Load Assemblies" message. Sometimes it takes quiet a few tries, but usually faster than restarting the Editor.

 

Is this related to this problem - it seems to lag on v2021.1.23 even on the simplest of functions, such as:

 

The assembly lock bug seems to have been fixed in 2021.2.1f1:
https://issuetracker.unity3d.com/is...er-opening-and-closing-openfolderpanel-window

 

I use 2021.2.1f1but it still happens.