Official Improving iteration time on C# script changes

For me it now only happens if I edit the script while it's compiling, and then another quick change to script will fix the error. So it's not fully fixed, but a lot better.

 

I tried this, but I could not make it to happen.. Or I am really suck at doing it "quickly"...

In any case, this is REALLY annoying.. I have to restart Unity again and again!

 

Yeah. Still happens

 

Yeah, but it got a little bit less often for me. Also today they released a new version of VS package, which I think completely fixed it for me.

 

I've just updated to Unity 2021.2.1f1 and the new VS package (2.0.12) and my busy time after editing scripts for a fairly large project is back down to about 7 seconds, where previously it had crept up to around 20-25 seconds.

 

Time to update!

 

After a few days of using the new VS package + 2021.2.1f1, I can say that the issue is still there but a lot frequent that before. Still annoying that sometimes I have to do changes until it starts reloading the assemblies.

 

You don't need to change any script. Just click play and the bar Reloading Assemblies pops up and holds the editor for about half a minute. Something is clearly not right in the last iterations. Instead of feeding with more content to the engine a serious clean up must be a priority before it becomes unsuitable.

 

I can confirm that the issue is related with the 2021 iteration. I have retaken a project that was on hold from one year and the last backup was using the 2019 version and there are not waiting times or reloading assemblies. Runs smoothly as it should be.
I have being working with the this project for a week after upgrading to the new 2021 and every change in the scripts or hit the play without modifying anything takes a minimun of 20-30 seconds of waiting.
Unfortunately, it will be hard for me to track the modifications and I can't downgrade the proyect to the previous 2019 version. Although I would consider that option.

EDIT: I downgraded my project by exporting as a package and loading into the previous 2019 Unity version. Definitely a 2021 issue. I will keep working with the 2019 version until this issue is properly addressed.

 

I don't see anyone making a video tutorial of developing with Unity. Until this issue is fixed they will only show how frustratingly clumsy is now if they have to halt half a minute for every step.

 

I've started to remove the Visual Scripting package from every single new project, as I found it to cause increased compilation time. It also feels like it's one of the main causes for the random loading bars that nobody knows where they come from. Once I removed it they kind of just stopped.

 

i had to reopen a unity 2018 project last week. That was sooo fast! I want unity to become like this again

 

It's like that in the alpha, you can also disable domain reload when entering play mode to make the enter time sub 1 second

 

Just to add to this, when the Plastic SCM window in Unity is open this issue is far far worse, waiting for 5 minutes at a time just pressing the play button. So best to stick to the third-party Plastic SCM Client

 

Just Removed the Following Packages in a clean Unity 2020.3.22f1 Project:
Version Control
JetBrains Rider Editor
Visual Studio Code Editor
Updated Visual Studio Editor to 2.0.12

The Compile Time for an empty project is 1.5 Seconds now. This is pretty much the same that I had with Unity 2019. Without the above tweaks its 1.9 Seconds btw.

I applied the same on my Production Project with around 50 Scripts (the rest is in dlls or Plugin Folders) and its around 3.9- 4 Seconds from saving til editor is responsive again

Thanks Unity! (Edit, i just saw that sounded sarcastic, i mean thanks for real. 2020lts is nice and snappy)

Edit:
Just did a test with the latest 2021 Version
Compile times Unity 2021.2.2f1:
Default: 2.9s
with the same "tweaks" there was no change at all. removing the visual scripting pack made it 0.1 seconds faster but not noticeable fast. Also removing every package never made the compiles go under 2.7 seconds

So that still means 2021 needs twice as much time as the latest 2020 version

 

I'm having really slow Reload Script Assemblies on a MRTK Hololens project. (3-5 seconds).

I am using Unity 2021.1.28f1, would Unity 2020.3 LTS be faster?

 

LTS is typically not faster, you could try on the recent alpha builds as a test, they perform better than any past version for me @havokentity

 

I'm curious to know what architectural changes in Unity 2020.x contribute to slow editor iteration. I find the notion that this was a gradual build-up over time a little incredulous because of our collective observation that there is a night and day difference between 2019 and 2020/2021.

Is slow iteration exacerbated by the move to packages, which brought new architectural requirements for compilation and assembly reloads?

 

Thank you I will try that

 

I've never had such long wait times with Unity until 2021.1 (I skipped 2020), I'm having extended wait times on pretty much every thing, loading, compiling scripts, starting Unity, exiting unity. It takes several minutes just to let Unity have a deep, philosophical thought about what it is in life. We are stuck to this version in work unfortunately.

 

Loading a new project has been sitting at ~2,5 minutes for me for years now. Loading existing ones takes about 10-20 seconds, though I don't have any real big ones.

 

I have gotten better reload assembly times with Unity 2021.2.2 but it crashes often so I am rolling back and maybe try new versions as they come out

 

Main issue for me -- well, I want it to be faster in general -- but the main regression that I'm seeing is that saving a file externally triggers the reload right away.

For example, let's say I'm doing a small feature addition or refactor and I've made changes across 4 different files (in Visual Studio), but I have *not* yet saved [any] of those files. Now, I'm ready to test my changes so, still with my "OS focus" on VS, I save one of the files -- that immediately causes Unity to recompile -- meanwhile I'm still in VS, I haven't even CMD-TAB'd back to Unity yet, and I still have 3 more files to save. I switch to the next edited file in VS, CMD+S to save it and, again, Unity recompiles immediately; yet I still have 2 more files to save!

I thought the old behavior was that Unity didn't recompile until you switched focus back to Unity?

The "overall speed" regression wouldn't be so bad (though obviously not desirable, either) if it wasn't recompiling after each individual file is saved.

The workaround posted near the beginning of this thread is my current saving grace -- basically disable the "auto-refresh" and add the editor-script for "Enter Play Mode". That works, the only downside is when working on editor code, you have to remember to CMD+R -- but that's not so bad (a while back we used to have to use an editor script to force Unity to exit play mode when code changed, before that was a built-in setting).

The workaround isn't awful -- I got used to it pretty quick even -- but I'd still prefer that it didn't "auto-refresh" / re-compile at all *until* Unity became the focused window.

I'm also wondering though (and I saw upthread, someone mentioned "see if it happens with edits in Notepad"), if what I'm seeing is either specific to Visual Studio (though I did disable the VS integration & had same results), or maybe even specific to VS-for-Mac? It looks like it's an AssetDatabase "check" though (ie any filesystem change is triggering it), but I admittedly didn't test that part -- in any case, if it could just wait to "check" until Unity is focused again, that would be totally workable in the interim (and even long-term, when the reload is faster, I still don't want it reloading N-times just because I made 1-line changes across N distinct files -- just reload once, upon TAB'ing back into Unity).

LMK if I'm missing something obvious, though! =D

 

CMD+SHIFT+S? Why not

Save all

if you want to save all? Then you only save once.

(beside the fair point to fix the recompile whenever a breeze blows)

 

I always use

Save all

, not only because of the unity compiler, it is faster, and I also make sure that I haven't accidentally forgotten to save a file.

 

You can disable this feature in the Unity Tools for Visual Studio settings under Tools->Options.

 

This does appear to have resolved my issue. I actually had the "Unity Project Explorer" disabled, which I thought cut off all edit-time [ie non-debugger] stuff, but I guess not. I have it disabled as it causes slowness in VS for Mac -- they worked on it & improved it some, but it's still quirky/not as fast when enabled vs disabled.

I wasn't aware of the setting you mentioned, though! And it did seem to do the trick for me -- appears to only be compiling when focus switches back to Unity now, which is how I thought it had always worked before (maybe that setting is new for VS-for-Mac, not sure?).

Thank you @strich !!

Edit: Also, WRT 'save all' -- yeah, I'm aware. It's just old habit from 20 years of development, I suppose. I tend to go through my code changes file-by-file, giving them a visual "once-over" before I save them, and after thinking about it for purposes of this thread, I actually do so more slowly/methodically than I realized -- I guess it's in an effort to spot anything I missed/forgot, or something, not certain. I do now realize that I definitely save my changes that way pretty much every time, and it's not that I'm unaware of 'save all' (and the shortcut is "loaded" / in-memory), it's just pure habit the way I normally write code -- though there are some rare occasions I use save all (typically when I have lots of files open & used refactoring tools to do a mass-rename or similar), but it's just not my 'norm'.

 

I think I don't understand something and maybe it has something to do with our different habits. If you don't save files in rapid succession, then why does it matter what Unity does or does not do in the background? Is it hijacking your focus or something?

I'm asking because I find especially pleasant when I switch back to Unity and I find that everything is already compiled, it doesn't hang on me or goes unresponsive with the infamous "hang on" dialog.

 

Yeah, precisely -- the editor "progress dialog" popup was actually displaying above VS despite Unity not stealing focus, the progress dialog was displaying on-top (but it was not focused, either / VS still had focus). It was also just causing an overall system slowdown, though that may have only been on M1 mac (which I'm using the native Unity on [2021.2x IIRC]), but I don't recall for sure if it was an issue on M1 only or not, TBH. I actually only upped Unity versions because of compile time being so bad on M1 -- upgrading improved/fixed that issue, but then this issue hit.

Though now I'm sailing pretty smooth again, thanks to the super helpful post above WRT the "Refresh Asset DB" setting. =)

What I can say is: at one point I had saved [habit] and then immediately saw I missed something & so typed out half a line of code -- none of my "already-typed" text was visible yet though & the progress-dialog was overlaying VS -- once the dialog went away [or possibly just before it, even], the 'already typed' text appeared... Basically it was painful enough that I googled & landed here in this thread. =D

 

These are things that often bothers me with MacOS, windows/dialogues that simply move to the foreground, even when the program is running in the background. Especially annoying with progress popups.

 

any updates on this topic? i just installed the latest 2021 but it looks that there are zero improvements on the slow compile times. Any roadmap about when things will improve or is it a "sorry, deal with it" thing now?

 

@xoofx @JoshPeterson

Stephen Toub's blog series on .NET 5 and .NET 6 performance is executed exceptionally well. This is the kind of public effort I think Unity needs to engage in to be successful.

1. You can't improve what you don't measure. Don't tell us a feature is faster -- show us through meaningful benchmarks.
2. Performance is a feature. A performance culture is key to long-term success. A feature does not ship unless the performance is quantitatively known in advance.
3. Improvements are communicated publicly.

I can't speak for the present, but historically I believe these measures were inadequate @ Unity.

Going forward, I'm hoping to see a matrix with release version, mean, and ratio as shown in the .NET performance series shared above. Based on Unity's history here nothing else will be credible.

 

I'm also having unmanageably long wait times when making code changes in 2021.2. I've been using unity for 8 years & it's genuinely scary to me how the product could have gotten so broken seemingly overnight.

Without a reliable answer to when this will be fixed my project is caught between unity versions. I have no choice but to downgrade, but was relying on some of the other new features in 2021.2 for URP

i really appreciate the effort that the workers at unity are putting into fixing this. i just wish those at higher levels in the company would recognize this as a critical issue. but maybe that's too much to ask when they need something sparkly to show to their new shareholders

 

I created a new project in 2021.2.5f1 with the 2D mobile template. After 6 minutes I had to close it and restart in a lower version. New versions are incredibly slow....



The amazing part is I'm using a 980 EVO, so the disk speed should not be an issue...

 

My temporary way now for 2021.2.5f1 is using disabled auto refresh and create a button for compiling script and play. I also change shortcut CMD + P to that action
It took 2-5s compliling for a small project (on Mac M1)

 

Guys you are not reassuring me with those Unity 2021 feedbacks. Is this happening for everyone or are there people for who it's super fast? Any way, unity guys will soon be preoccupied by chritsmass trees and stuffed tukeys so I guess I will have to check for advancement sometimes mid january next year.

 

I'm using 2021 for a number of projects and performance isn't a problem at all.

 

The performance issue relates to the number of assets stored in the asset database, number of classes compiled, and number of assemblies reloaded into the editor app domain. It isn't unusual for projects to have 20,000+ assets, 5,000+ classes (including scripts), and tens of assemblies. The iteration performance for large projects in Unity is unworkable. It's broken, defective, and completely unusable. This poor iteration performance was caused by new features and architectural changes introduced in 2020/2021.x.

 

Unity 2019 LTS is by far the fastest, but the new introduced features might be the deal breaker here for 2021.x

 

In case anyone in this thread misses it. The 2022 beta supposedly improves iteration times.

https://blog.unity.com/technology/unity-20221-beta-is-now-available-for-feedback

 

Just checked. Zero changes or improvements on the compilation time from the latest 2021 to 2022 on an empty project (2.8 seconds vs 1.5 seconds on unity 2019lts)

 

After unity ran for hours, enter game mode is very slow with VS attached. Assembly reloading toke 119643ms. (And VS attaching cause Unity hang for minutes.)

Unity2021.1.19f1, VS2022.

editor log:

Reloading assemblies for play mode.
Begin MonoManager ReloadAssembly
AcceleratorClientConnectionCallback - disconnected - 10.7.3.59:8000
Native extension for WindowsStandalone target not found
Native extension for Android target not found
Refreshing native plugins compatible for Editor in 68.19 ms, found 15 plugins.
Preloading 0 native plugins for Editor in 0.00 ms.
Refreshing native plugins compatible for Editor in 2.20 ms, found 15 plugins.
[MODES] ModeService[none].Initialize
[MODES] ModeService[none].LoadModes
[MODES] Loading mode Default (0) for mode-current-id-HexTile
Mono: successfully reloaded assembly
- Completed reload, in 119.595 seconds
Domain Reload Profiling:
ReloadAssembly (119643ms)
BeginReloadAssembly (52818ms)
ExecutionOrderSort (0ms)
DisableScriptedObjects (266ms)
BackupInstance (0ms)
ReleaseScriptingObjects (0ms)
CreateAndSetChildDomain (42424ms)
EndReloadAssembly (66628ms)
LoadAssemblies (11465ms)
RebuildTransferFunctionScriptingTraits (0ms)
SetupTypeCache (1567ms)
ReleaseScriptCaches (2ms)
RebuildScriptCaches (84ms)
SetupLoadedEditorAssemblies (5029ms)
LogAssemblyErrors (0ms)
InitializePlatformSupportModulesInManaged (8ms)
SetLoadedEditorAssemblies (0ms)
RefreshPlugins (68ms)
BeforeProcessingInitializeOnLoad (1311ms)
ProcessInitializeOnLoadAttributes (2941ms)
ProcessInitializeOnLoadMethodAttributes (694ms)
AfterProcessingInitializeOnLoad (7ms)
EditorAssembliesLoaded (0ms)
ExecutionOrderSort2 (0ms)
AwakeInstancesAfterBackupRestoration (539ms)
Platform modules already initialized, skipping

 

i have this issue too!!!!!!!!!!!!!!!!!!!

 

When it comes to these issues, is it related to the C# framework/constraints, or Unity? Imagine if some intelligent design meant that, changing x = 1 to x = 2, simply hacks the build and edits 4 bytes and anything that might reference that.

Never understood why a whole program needs to recompile if you change 1 tiny thing and not anything to do with the structure. Surely there are patterns. Find the patterns, solve it sideways haha

 

The recompiling part is pretty fast (almost instantaneous), reloading the assemblies is the slow part. When you change something in the code Editor has to reload all of the assemblies and redraw the UI because anything in the code could possibly change the Editor's behavior, even if it's not in the Editor Assemblies, for example the Monobehaviour properties that Editor shows on the inspector.

To test this, make an error in your script and see how fast Editor will show you an error message in the console (on my machine takes less than a second). For that it has to recompile your scripts.

 

Well wish I knew more about these things, there must be some way to reload intelligently without the brute force nature of reloading everything. Maybe this is a Net/C# constraint, but can't it be overruled? Initially assemblies compiled, loaded into memory but also mapped somewhere (memory to burn option on). On recompile, assemblies checked against previous versions, memory/pointers updated against changes.

 

Yeah, so "reloading assemblies" just means reloading all the code, and changing all the live data.

The changing all the live data part is hard, because it might be that some change you did to the code means that the types of the data is larger now, so in those cases trying to read the old data with the new types would just give garbage.

A smart system can tell if all the changes you did were to methods, and not the layout of types. In those cases it could elect to not redo all the data. But figuring out when you can do that is a hard problem to solve, and systems can be a lot simpler if they can assume that everytime anything changes, everything has to be reloaded from scratch.

 

Most of us would agree that the assembly reload iteration issue does not exist or is unnoticeable in 2019.x. How was iteration successfully accomplished in 2019.x?

 

I think it started when asset database v 2 got introduced. But whatever is happening around that topic, the information flow is non existent

 

It doesn't but almost. 2020.1.17f1 is still as good as 2019.4.x and both make use of v2.

Btw, I changed all my scripts to a custom assembly and now it compiles way faster than when they were in Assembly-CSharp. The editor gets "busy" for minutes, but at least compilation times improved. 2021.2.7f1 lead me to:



And it takes now 80% of my i7-7700K and between 5-8GB of RAM everytime I try to import an asset no matter how big the project is. It looks like they fix something and then break other that worked before.