Official Improving iteration time on C# script changes

Yeah, my bad. 2019 used v2, i just had it set to v1. Latest 2020 showing good compile times. Esp, when uninstalling not used packages(rider, version control etc) and upgrading the latest visual studio pack.

so its pretty much „just“ 2021/2022 that’s behaving bad

 

i have fix something like this ...

i check all the editor window class. and add OnDisable() {} to make sure all scriptobject load to set null or use Editor.DestroyImmediate()
after all this use the EditorUtility.UnloadUnusedAssetsImmediate() to gc.

hope this help you.

 

Not sure if i understand this right. How is this improving the c# compile times?

 

you should delete & gc all your asset in editor class when OnDisable

 

I am still confused. On disable never gets called when i compile a script

Do you have an example script or project that shows what you are doing?

 

some things like this. after i have done this modify of editor class...

 

Hi @xoofx. It has been 80 days since we last heard anything. Just wondering what the status is for this critical issue.

 

My scenario even worse - Reload Script Assemblies pops up every time I enter Play mode in the editor.
And it happens without even making any changes to C# scripts.

(Project Settings > Editor > Enter Play Mode Settings > Domain Reload is Off)

So to me it seems like the issue is not 100% related to compilation times after some of the scripts were modified. I created separate thread.

https://forum.unity.com/threads/rel...pon-every-play-stop-in-empty-project.1221063/

 

For me, it get worse while VS debugger attached.

 

I'm also having trouble with very long domain reload times, but I feel like there is something more going on in my instance. Specifically the CreateAndSetChildDomain (unload domain) is taking a very long time for me. I've waited with digging deeper until now because I just started looking into upgrading from 2020.3 to 2021.2. In the new version, it seems like assembly reloads either occur more often, or at least the problem is much more consistent. I simply need to reimport a script in the root Assets folder, at which point I need to wait 1-2 minutes for the reload:

I've tried turning on "EnableDomainReloadTimings" in the diagnostics preferences, but unfortunately this specific item doesn't provide any more information. I've also tried deep profiling + editor iteration profiler, which after crashing my pc or unity 3x (over 28GB mem usage ) gave me almost nothing, other than noting the time was mostly part of unloading the unity domain.

Currently trying to figure out what could be causing the domain to be so large (or difficult to unload) but not sure how to go about doing that. There is one plugin in my project that once removed seems to "resolve" the issue, but that could also just be a ghost I'm chasing. Diving deeper into that now, will update if I find anything.

edit: I've found the root cause of my specific issue, and it was related to the plugin I mentioned containing a MonoBehaviour with a constructor & destructor, and using that monobehaviour in over 80000+ objects in scenes/prefabs, triggering code whenever unity would reload its domain even if in an empty scene. Was able to work around it so its not nearly this bad ^^

 

I logged into FogBugz to check on the status of the asset refresh bug I submitted (1376641) with supporting screenshots and editor iteration data. The associated data shows AssetDatabase.Refresh and Application.UpdateScene occurring twice per editor iteration, which effectively doubles the time it takes before the editor is usable.

My report was submitted over 75 days ago and there has been no response. Similarly, there have been no new updates to this forum thread in nearly three months. I'm not sure who to page at Unity.
@xoofx or @lyndon_unity @JoshPeterson What's going on with editor iteration performance? Is there quantitative progress you can share?

 

And there is not any unity release after 2021.2.7 released for a month.

 

I mean anything in a 'Plugins' folder (which most of your plugins should already be going to) will also go into the the Assembly-CSharp-firstpass assembly. Source: https://docs.unity3d.com/Manual/ScriptCompileOrderFolders.html

 

It was holiday season, what did you expect?

 

2021.2.8f1 just came out and it doesn't solve any issue so after a month we are still in the same boat :/

 

+1 to this whole thread as I've resorted to doing any sort of scripting prototyping in 2018.4.36 simply because it's quick. This is a really poor workaround as eventually I have to make edits to my projects in the 2021.2.5 build and those are taking 20 seconds or more from saving a script edit to getting into play mode due to the time it takes to reload script assemblies. It's just impossible to stay in any sort of cognitive flow with that much of a wait time.

 

My 5900x died and took windows with it, picked up a 12900kf and samsung 980 pro. I went from 15-20 second recompile and script reload to 5 seconds max on my new machine. Fingers crossed it stays this way

2021.2.6

 

Thanks for the thorough update. Are the improvements "for the upcoming public releases of 2020.3" listed in the 2020.3 table? If not, what gains can we expect?

 

Thanks for the update. Mostly I am worried that in the table 2020.3 might be seen as the ultimate benchmark and how the numbers in 2021/2022 should look like. Personally I would like to see the numbers of 2019LTS since it started to go downhill from there

script change:
2020LTS: 2.1s
2019LTS: 1.6s
2018LTS: 1.5s

new script:
2020LTS: 1.6s
2019LTS: 1.4s
2018LTS: 1.3s

"This is work in progress, we hope to be able to give you stats of the improvement in our next update post." any idea when this will be?

 

Pretty sad If the improvements do not make it to the versions most people will be using.

 

Many thanks, @Maria_Angelova.The quantitative performance comparisons show Unity's commitment to data-driven improvement. It is helpful to know these metrics show new and current versions of 2022 remain slower than 2020. The work that lies ahead for performance optimization is substantial and real. Thank you for your continued efforts.

 

Quantifying performance and sharing results is an important next step for the evolution of the editor. I'm very grateful for their commitment. I fully agree that 2019 measurements should be included. The measurement names would likely be different in 2019 due to architectural and asset pipeline changes. For this reason, a measurement of "total editor iteration time" for the 2019 editor and later versions would set the bar for excellence.

 

Will there be measurements for a project larger than the 3D template? That template doesn't exactly have a large number of scripts or assets. A shipped title on Unity will have several thousand assets and scripts...

 

2020.3.26 after importing an asset from the store (Enhanced Scroller):



And the symbol of "compiling" is stuck. :')

 

This isn't really related to this thread? This is about iteration time, not plugins causing Unity to get stuck.

 

@Maria_Angelova, I noticed that the VS package is more actively updated than VS Code.

Considering the VS Community license that ships with Unity doesn't allow for organisations with more than 5 users to use it - and that VS Code is generally more lightweight...

Does Unity have plans for at adding relevant optimisations to VS Code too?

Thank you.

 

Maybe we should work on preventing the editor from crashing after making changes to our scripts, rather than investigating a few milliseconds....This bug has been around since 2020.1 and still kicking in 2022.1b5

Not trying to crash the party, but force closing and reopening a crashed project takes about 5 minutes...if nothing gets corrupt...if I get lucky then I am stuck reimporting the project for about 2 hours. Then I have to inspect key assets to check if serialization didn't get messed up...

I appreciate the investigative effort...but also when my project crashes about 2~3 times every hour...and much much worse when I am working on scripts all day, I kind of wonder if this needs this much effort...while I am constantly reopening, force closing my project and spending about an hour on average everyday...

Personally, I get really scared sometimes to save the changes that I made to the script when I haven't closed and reopened my editor for a while, because when the editor crashes, all the changes that I made, unless another scene was loaded, gets lost. So I copy paste the whole script to Notepad+ and cancel save, save the editor and close the editor then reopen editor then copy scripts back to VS then save...this is my current, and most down to earth "iteration".

I wonder if Unity is even aware that most of its users are fighting the Engine half the time...I honestly hadn't noticed any performance regression as I am mostly praying during compilation...

Just my 2 cents.

 

While I can relate to all the people fighting with iteration times gone too far, I really can't say I have problems with Unity crashing. I can't even remember when Unity crashed on me last time - maybe 3-4 times per year? And especially during the compilation time, even I work on scripts like 80% of my game dev time. It rather happens in the editor itself.

So there must be something wrong with your environment when you get so many crashes - either your hardware (corrupt memory maybe) or the 3rd party scripts you have. I don't say Unity shouldn't handle faulty code by itself and prevent crashes but again, that's something you can investigate and fix on your side...

Do this happen to you even with fresh new projects from their templates?

 

We have had periods with Unity crashing on the regular. Can't remember all of them, but gut feeling is that about 50% was our fault, and 50% was Unity's fault.

In all instances it was possible to figure out why it was crashing regularly, and work around it. Sometimes that took a lot of work, but it was doable.

Unity doesn't "just crash for no reason". Delivering bug reports with the stack trace and being aggressive about giving more info has always solved it.

Posting "Unity crashes a lot for me, and I think it crashes a lot for everyone, so you should obviously be fixing that" isn't going to get much done.

 

What does the crash section of editor.log tell you? The stack trace of the crash is a good way to identify the cause. If you start a separate thread, since this one is dedicated to iteration performance of the editor, we can try to assist.

 

I want to join to this choir myself. Unity crashed on me in January, 2021, when the relatively new UI Builder was instable for some reason. Before that, Unity crashed in April of 2020, when I added a not supported (but undocumented) entry to the

.collabignore

file. And that's it. Unity takes crashes and crash reports very seriously. You should try to isolate the cause and if it turns out that Unity's fault, let them know.

 

I have a feeling @jjejj87 is referring to when Unity gets stuck indefinitely recompiling, rather that what you imagine by the term 'crashing'. It did used to happen to me regularly a number of Unity 2020 versions ago, and it was potentially caused by Odin but I don't think anyone found anything reproducible to make that connection. But after a few version updates those freezes have entirely ceased for me.

 

The thing is editor works just fine when the project is light. Now my project file is around 300gb and this editor acts like an eggshell now...

I've sent more than 20+ bug reports, but so far it is apparently not fixed
So I've given up hope. It will eventually get fixed in a few years. Gonna jump ship next project.

 

Is 300gb including the Library folder or just assets? Looking at your forum join date I suppose you're an experienced Unity user. I don't say projects can't go that big in size but are you sure you're using all those assets? Many beginner Unity developers just import assets from the store and don't use 90% of the stuff there, so it's always recommended to import things to temporary project and export just what you need as a package (including dependencies of course). Again, Unity itself should be capable of handling those sizes, but why cluttering the project if you don't need to, everything for sure would be faster with less assets...

 

Hey all,

Eagerly awaiting the optimizations (next month?). Using 2021.2, and with the Diagnostic switches turned on, I get the following:

Code (CSharp):

1.  
2. Asset Pipeline Refresh: Total: 8.100 seconds - Initiated by RefreshV2(AllowForceSynchronousImport)
3.         Summary:
4.                 Imports: total=1 (actual=0, local cache=1, cache server=0)
5.                 Asset DB Process Time: managed=0 ms, native=413 ms
6.                 Asset DB Callback time: managed=73 ms, native=9 ms
7.                 Scripting: domain reloads=1, domain reload time=5722 ms, compile time=1881 ms, other=0 ms
8.                 Project Asset Count: scripts=8621, non-scripts=4403
9.                 Asset File Changes: new=0, changed=1, moved=0, deleted=0
10.                 Scan Filter Count: 1
11.         InvokeBeforeRefreshCallbacks: 0.177ms
12.         ApplyChangesToAssetFolders: 0.065ms
13.         Scan: 159.472ms
14.         OnSourceAssetsModified: 0.825ms
15.         InitializeImportedAssetsSnapshot: 25.764ms
16.         GetAllGuidsForCategorization: 1.810ms
17.         CategorizeAssets: 148.141ms
18.         ImportOutOfDateAssets: 7629.724ms (5741.443ms without children)
19.                 CompileScripts: 1881.188ms
20.                 ReloadImportedAssets: 1.811ms
21.                 EnsureUptoDateAssetsAreRegisteredWithGuidPM: 2.997ms
22.                 InitializingProgressBar: 0.000ms
23.                 PostProcessAllAssetNotificationsAddChangedAssets: 1.800ms
24.                 OnDemandSchedulerStart: 0.486ms
25.         ReloadSourceAssets: 5.924ms
26.         UnloadImportedAssets: 2.177ms
27.         PostProcessAllAssets: 75.167ms
28.         Hotreload: 6.946ms
29.         GatherAllCurrentPrimaryArtifactRevisions: 0.573ms
30.         UnloadStreamsBegin: 0.069ms
31.         LoadedImportedAssetsSnapshotReleaseGCHandles: 2.769ms
32.         GetLoadedSourceAssetsSnapshot: 4.883ms
33.         PersistCurrentRevisions: 0.621ms
34.         UnloadStreamsEnd: 0.069ms
35.         GenerateScriptTypeHashes: 5.878ms
36.         Untracked: 110.086ms
37.  

I'm simply changing one character in a debug statement and it takes 10-12 seconds (even if it says 8.1 seconds there). Most of the time is in ImportOutOfDateAssets which is taking 7629ms.

Any workarounds for that or just have to wait?

 

I am using 2021.1.19f1 and am experiencing reload times of between 30-60 seconds on a brand new Mac M1.
Unity has become basically unusable for me.
Perhaps no-one at Unity has realised, but this is a problem.

 

Thanks for the awesome update! Even if the changes take time and are just small improvements at first I'm happy to see you are taking this seriously and including details on both what you are improving as well as the results so far. Looking forward to your next update!

 

@Der_Kevin Something feels rather wrong with that project if those are real times... Even if 2021 trippled the time compared to 2019, that would still have been about 8 minutes back then which still seems crazy. Have you tried re-importing the project once? And I guess you do not use any separated assemblies?

In every case according to the devs they haven't found a solution that would reduce the time by a magnitude or anything that significant.

 

For me reload times begin getting longer and longer until I restart Unity and then it is back to just normal (and relatively slow) for half an hour until it starts again. After 2 hours of working in Unity reload takes ~30 seconds compared to ~3 after restart. And I am using .asmdefs religiously so that should prevent everything from compiling each time.

Edit: Tried deep profiling and it seems that AssetDatabase.V2 is causing most of the issues and quite a lot of GC (this was one of the shorter reloads, just changing one line of code):

 

YES, that is something I experience too! Had assumed it was because I'm using an older beta version.

 

That was fixed for me in a later version of Unity. I think for me it was scriptableobject-related, where Unity would keep leaking memory and taking progressively longer to enter play mode.

 

Definitely not my experience.

It's good that you are improving things within the same major Unity versions, but from major version to major version it seems things are getting significantly slower across the board? This is a worrying trend.

 

This speeded up shutdown significantly (instant), not sure about anything else, but I hope so. Although Editor.Log doesn't say much change there.

Project Settings > Editor

Default changed to Parallel + 12 threads (hex-core)


Preferences > Asset Pipeline

Changed 25% of logical cores to 100% because why not

 

The version is 2021.3.10f1. I am not going to upgrade to 2022 as I was burned once already by the cutting edge release of Unity. Even 2021 is not the most stable but I liked the features.
Also, I do not have ScriptableObjects in the project.

 

Unfortunately seems to do nothing to the AssetDatabase.Refresh times. And that is on 12C/24T processor. My guess is that there is an option for the future changes but not much of the AssetDatabase is parallelized.

With parallel and 12 threads:


Without parallel:


Tried a few times with each setting just to get these parallel workers going. Same results.
In fact, it even seems to be slower when parallel is enabled. Tried it a few times, always changing the exact same constant in the script, and each time Parallel enabled was slower. Interesting.

 

Im absolutelly noobie for Unity and started up to watch first step manuals and found so every time between code savings and openings Unity - Unity spends about 10 sec (for relatively free project) to "rebuld" his project.... Every chage.. Spends about 10 secs... Look not quite good, especially when you relly noobie and after change some value want to see what changed in the Unity\Play mode - it spends about 30 secs summary.... Hoh, really, really not well...
What is the solution? I found this topic from Google, what is next steps, watch this thread for updates?