Official Improving iteration time on C# script changes

Here're the results: no improvement in my case.
If anything I found out that not having my 12.5 gigs of graphics assets and other small settings files reduced reload time by as much as 3 seconds why idfk they don't contain significant code files, maybe has to do with the asset data base refresh step even though that isn't what the profiler indicates as a big offender.

Will need to do more testing but I don't like the idea of having to make a duplicate proj for faster iteration.

 

So in April 2022 I moved a small 2019 project to 2021.3? and it was horrible and I reverted. I experienced all the issues mentioned in these last nine pages.

What's the current situation and status? Where is Unity with all this? What are we looking at near and mid term on this issue? Do we just eat the iteration time and #dealwithit as the New Normal?

I know that console ports are an issue for 2019, etc.

 

I don't know how, or why, but this here, is just simply amazing. Constantly see that stupid bloody Progress Bar, it seems the longer and more the project is open and managed, the worse it gets, from 10 - 17 - 32 - 1:02 seconds ... seriously ... wtf. Sometimes after just changing a single internal non serialized float value ... O,o.

Anyways , i made this change, and though it takes a bit to get in the habit of ctrl + r all the time, it is lightning responsive and fast in contrast. Maybe it dont work for everyone, but it sure did for me. Thanks mate. Appreciated.

 

I started learning Unity today, and my first tutorial showed how to create a script that said "Hello World!" on the console.

After I saved a single line code change in VSCode, Unity takes around 5 seconds to "Reload Script Assemblies".
This didn't make sense, so I searched online thinking I made some configuration error, and found this thread.

If 5 seconds reload time on my first hour learning unity was unnaceptable to me, I feel for the people having to wait minutes for a single line change.

I appreciate the team taking this seriously, but as someone working on big tech for almost a decade, treat this with maximum priority as this will cost user trust in the long run.

A "Hello World" project should run in almost instant time, 5 seconds may disencourage begginers to keep learning.

 

i am gonna answer this quickly with all possible answers that you can expect:
- BUT UNREAL TAKES WAY LONGER!!!
- laughs in godot
- we are working on it but its not that simple
- 5 seconds sounds like a lot, there must be something wrong on your end
- can you file a bugreport and upload the project
- exclude your project from the windows defender thing. it wont help but that way we can blame someone else
- we have no idea but LOOK AT OUR NEW HAIR RENDERER!!!

 

So true
This hurts me as a previous Godot programmer! But I'm gonna stay with Unity for now as I'm doing 3D and Unity's more flexible...

But if you're a beginner ( which you definitely aren't ) then just use Godot... It even has Rust Bindings which I might try out the next time I use Godot!

 

2019 LTS is the fastest version right now so you can stick with it

 

Unreal doesn't take longer btw. Especially with hot reload in ue5. I won't even mention blueprints

 

I don't know if that changed in 5.1, but if you restart the editor and you used hotreload, all the changes since the last full compile were completely gone, you then have to close the editor, recompile the project in the IDE and then restart the editor. If you don't know this, it can quickly leads to confusion and data loss.

 

happy cakeday dear thread

 

I don’t think that is a good thing…

 

@xoofx, @Maria_Angelova, and Unity Performance Task Force: I have suffered a long year since Xoofx made his post on 10/18/2021 documenting editor iteration issues and the creation of a task force to address it.

My question is specific -- for projects containing a large number of assets and scripts. e.g. commercial use of the editor, is the iteration issue manifest by changing a single C# script resolved? The issue is further documented here (https://issuetracker.unity3d.com/issues/increased-reload-time). The behavior is not present in the 2019.3 editor, and it is manifest in 2020.x and all subsequent versions.

*** If it is not resolved what is the time frame for resolution?

Thanks,
Shaun

 

I tested on 2 projects one of which is a commercial sizable project on 2019 LTS, 2020 LTS and 2022: the iteration time is roughly the same in my case.
The only diff is instead of the bar saying "Reload script assemblies" it says something else like "Importing XYZ" but if you use the profiler you'll see the same big offenders having the same names like "Refreshing database V..." or something like "refreshing out of date assets".

The issue is that I don't even remember ever having had or the last time I had 5 seconds or less of iteration time since I started working on this project back in Unity 2018
None of the 2022.2 betas improved iteration time, noticeably at least cuz I did timing logs.

 

It is most certainly not resolved. On 2022.1 myself, and even in a relatively small project, it's taking 30-40 seconds to "Reload Script Assemblies".
Iterative development with this is excruciating.

 

After banging my head against this for a day or two, I did find a solution that's good enough for now in 2022.1:
1) Get rid of the bloatware in the package manager. Most folks only need 3-4 of the built-in packages, not the dozen or so they include by default.
2) Disable domain reloads in the Project Editor settings (but make sure you code for that).
3) Close Unity and its launcher. Delete the Library folder. Re-open Unity and let it rebuild the Library folder (this can take a bit).

After that, my wait-between-iterations time went from 30-40 seconds to 2-5 seconds... much easier to deal with.

 

That's actually always the first thing I do when I create a new project. Especially visual scripting and all the IDE packages of the IDEs I don't use.

 

Yeah no the IDE packages especially make Unity super slow for no reason!!! Remove all of them and keep only the one you will use!

 

I think ive said it before, but if you open unity with the -noUpm command, its so fast.

sure, no more packages for you anymore and not a useful workaround but… eh.. i forgot what i wanted to say… something something pacakage manager

 

For clarification, it's not that the package manager would actively slow down anything. It's just the fact that there is so much C# code loaded nowadays.

It does depend on the machine though. No significant issues with an R9 3900X.

 

Yeah, I didn't realize it was so necessary with newer versions.

I remember older versions of Unity having checkboxes to let you choose what to include in the New Project window. I wonder what ever happened to that.

 

Probably because you're using a high-end chip that can utilize parallel import, that means threads as you have 12 cores and 24 threads!!!

 

It is 2 generations old already though and you get a bundle with a board and ram for about 650$. That should be worth it for proper game dev...
Sure, people who are bound to a notebook have it tougher.

 

These are the modules during installation, but these are usually platform targets., packages are project-related.

 

We are talking about script iteration time here, right? Thats only singlecore. So a 12900k(s) or 7950x would be your best purchase for that

 

I just finished assembling an AIO-cooled AMD 7950x w/ PCIe 4.0 NVME and 32 GB of DDR-6000 RAM. I built this beast for one reason: Unity editor iteration time. It is a sad state of affairs to throw hardware at the problem... especially when we know that 2019.x had no iteration issues.

I'm reimporting project assets right now and what does one do while waiting on Unity? Check this thread! I always hope I'll return and find that @xoofx and team has resolved script iteration issues.

 

Same:
https://docs.google.com/spreadsheets/d/1A2laLkhK9qigmxlJd_QRNQGiAopaXvioycCwuay9oT0/edit?usp=sharing

I think the people saying that 2019 was the bee's knee's used the version before the flat redesign, it was noticeably faster.

A side story: 4.7 is 2x to 3x faster at domain reload so something happened. My guess is that editor code was moved from c++ to c#, creating many more states that now compete with our own code to be processed during domain reload.

 

my guess is, if you switch from asset database v2 to v1 in unity 2019, you will see some waiting time improvements

 

Yes I read other people mentioning the same thing notably the packages.

Unfortunately they removed that option in the LTS of 2019 and I also read someone suspecting the issue originating from the transition from v1 to v2.

Either way reverting back to 2019 comes with other speed tradeoffs like significant import times, initial project opening speed and other in-editor speed improvements like selecting a large number of objects or say a large Light probes group not to mention API and other features.
So in my case I'd take the 9-13s iteration time over the mentioned tradeoffs and will keep testing the 2022.2 betas from times to times to check for any significant improvements in the meantime.

 

Unity Technologies will not fix this because this is not a problem for their shareholders. ATM they are too busy making yet another hair tech demo.

 

Hello!

We were experiencing a huge degradation on iteration times when changing a line of code and switching back to the Editor, or after pressing the Play button, starting on 2020.3.30f1. After investigating and discussing with Unity, we found out that the cause was a a change in the Package Manager introduced in 2020.3.31 and that was made even worse on 2020.3.34. All Unity versions since then, have this problem.

This was specially noticeable if you are using a lot of packages or packages with lots of versions (for example, if you use a private npm repository like artifactory).

Now, Unity has released 2021.3.12f1 that fixes this problem. The backport to 2020 is coming soon. Give it a go and see if it improves things for you.

The relevant line in the official release notes:

• Package Manager: Fixed an issue where having packages with a lot of versions increases domain reload time drastically. (UUM-12670)
  

 

In the bug report it says the package manager has to be open for the issue to occur. This isn't the problem most of us are discussing here but thanks for the info regardless.

 

It is not true. The issue was happening regardless if the Package Manager window was open or not.

The important bit also is that this bug was impacting the Domain Reload, so the result is that you were seeing the Unity dialog "Reload Script Assemblies" for a long time after changing a script, pressing the Play button, etc.

 

Yeah, but I'm using 2021.3.12f currently and... no improvements for me...
It still feels like the same speed, but this might've only impacted bigger projects, which I currently don't possess.

 

Same here, every change takes from 40s to ~1-2 mins even in small projects with code separated in diff assemblies

 

So now I need to ask how big your project is...
Because if your project is humongus then 40s makes sense...

Assembly Definitions don't do sh*t about assembly reload time ( I know missleading name )

They only speed up compilation time, which is super fast ( sub-seconds ), BUT if you don't do it you can easily get up to 5s of compilation time ( NOT assembly reload ) extra...
Also it forces you to structure your project

Thing is me personally I have about 6s for a small change in a script and multiple changes take more about 20s MAX...

I have to say I reinstalled windows a long time ago and if I'm remembering this correctly it was way worse before the reinstall ( maybe on a normal occurance 25-30s ish ), but this isn't a viable solution for everyone or even businesses.

 

Oh and also this is nowhere close to what it used to be…

The sweet old days of literal millisecond reloads are over I guess… and it seems to be an issue with C# as a language not supporting ways to have precompiled binaries or hot reload or smth idk…

I heard though that all of this stuff so AOT and hot reload are being worked on in .NET 7 and Unity is trying to migrate to that.

We just have to wait super long

 

Wow reading that thread, I wish we'd get as many proactive updates here. Seriously the devs over there pop up pretty regularly. Good on them. Been months since an update on this issue.

 

Do you have this also if you disable domain reload in the configuration?
https://docs.unity3d.com/Manual/DomainReloading.html

 

No... but this creates worse problems...

The whole point of reloading the assemblies is to unload any static instances/fields/vars, that are left which might cause unexpected behaviour. By doing what you're suggesting, you're disabling that as a whole, meaning I have to uninitialize every Singleton every static value and think about uninitializing it when writing code.

When I get a bug I need to remember that, that might be the cause, not to mention that alot of Unity Assets aren't accustomed to disabling this option ( A* Pathfinding a couple months ago!!! now it's fixed )

Also this seems to be a huge project that they're working on...

 

I have turned off Auto Refresh and Directory monitoring, so when i change code it does not recompile. However, every time i delete a file, ti will recompile, which is very annoying when trying to clean up. Is it possible to disable this too?

 

For Singletons and static values use a script that has its event order set to -999 and initialize them all (aka force overwrite the static value) in the awake or even just start method.

The linked article provides info on how to cover more general cases.

On "small projects" it's not a hassle. I did switch a project fairly late to this mode.

 

It happens to every project, big and small. Bigger projects take way longer obviously but projects with a single script takes from 15-30seconds to reload. And this is a thing since 2020.1.17f1 (9 Dec, 2020) or so...

 

Ok I know I'm starting to ask for too much, but...
what are your specs...
because I'm on a laptop with an i5-10300H and that isn't truly high-end.

AGAIN I did reinstall windows a good while ago and it did become faster if I remember correctly, soooo

 

Every end user has a different experience with editor iteration because every project is different.

I'm running an AMD 7950x w/ 8Gb/s NVME and Unity iteration limps along. It is a better experience on high-end hardware, but I still experience iteration wait times that vary from a few seconds to several minutes (2), (3).

• Yes, I'm running a completely new install of Windows.
• Yes, real-time antivirus has an exception for the project folder.
• Yes, the library output folder was rebuilt.
• Yes, installed packages are an absolute minimum.
• Yes, domain reload is disabled and scene backup is disabled.

Anyone who hasn't experienced the slow-down should test with 5,000 class files and 50,000 assets and let us know what your experience is like (1).

Iteration is slow because Unity does not scale with large projects.

The Unity team acknowledges editor iteration performance issues. The lack of communication is likely due to a lack of progress. Unity either can't or won't fix the issue. Will they fix it in the switch to a .NET Core (.NET 7) runtime?

(1) An assets directory with a large number of files (38,413 files comprising scripts, textures, models, and metadata) affects v2 asset database performance. Editor iteration is slow, and this slowness has been reported to the Unity team in this forum thread, other forum threads, and through submitted issues ad nauseam.


(2) An example of the infamous Reloading Script Assemblies bug that hangs for a long time. Notice how CPU utilization and disk utilization is zero. The editor is blocking but no real work is being done. See "Reload Script Assemblies (busy for 01:18)..."



(3) A continuation of the above example showing processor utilization by all Unity process is 0%. "Reload Script Assemblies (busy for 02:59)..."


The above behaviors are bugs. It could be a deadlock issue or an issue with the Unity editor. It has been two years since the issue was first reported in these forums. @xoofx @JoshPeterson @Tautvydas-Zilys It is Unity's responsibility to take our feedback, reproduction steps, and logs to find a resolution for these bugs.

The break-down in accountability for this long-standing issue is real.

• We ask for frequent updates and beyond an initial post here (with commitments to keep us updated) they largely ignore us. I believe it has been over a year since we have had an official response.
• We ask for quantifiable data to show progress. The data previously shown indicates a decrease in performance.
• As paying users we ask for a timeline for resolution but again there is radio silence.

I don't have an axe to grind with Unity. I love Unity and this is the source of my passion. I want to see it succeed. Unity faces existential threats over the next five years and this issue matters. I have colleagues who have stopped using Unity because of iteration performance issues. Unity has to do better.

 

I honestly wouldn't be surprised if they're just waiting on the .NET 6+ switch. From reading the other thread, it *seems* like they already need to do some rewriting of domain reload to support hot reloading? If this is correct, maybe they don't want to use resources fixing issues with the current setup knowing it's just going to be replaced?

 

Exactly!
I think that their whole domain reloading solution either has become super flawed to the point that it's better to wait for .NET 7...
or
...They want to focus their Resources onto the more ambitious goal of changing to .NET...

First of all thank you for this lengthy post! It helps not only me, someone who followed this thread as a solo-dev for a long time, but others coming to the post understand what the current issues are!

The thing that is weird is that these "deadlocks" get opened after a while...

• So either it is an issue of Unity not being multi-threaded as an editor and a lot of the tasks in the editor are FORCED to being performed single-threadedly...
• Or these "deadlocks" open after failing for a while ( of course they aren't really deadlocks by then, otherwise the program would just crash ) where the short time solution is to lower the fail time threshold.

 

After reading this thread, the idea came up to remove unused Packages from the Project...

After removing a few of these unused Packages, the compilation issue seems to be fixed... I am barely hanging up anymore, and compilation is back to near instant. No more one line changes forcing tens of seconds of compilation hang-up.

I did not remove any Built-In packages, I only removed packages from the "In Project" tab. Some of the packages I removed included:
- Jet Brains Rider Editor support
- Visual Studio "Code" Editor Support
- Two XR support packages
- Maybe one or two others that I can't even remember

I simply removed packages that I'm not using at all... And now I'm not having these ridiculous compilation/assembly hang-ups. There are a few more packages that I don't use, but they are still in there. So it doesn't seem to be a bloating issue of having too many unused packages...

Instead, there is a good shot one of the XR packages, or the Jet Brains support package has a serious implementation issue. Or maybe one of the packages that I don't remember removing...

Give this a shot, it is working for me.

 

I had an odd experience once. I installed a new version. My first thought was whether domain reload had been improved. I tested with a blank project, many opens and closes, it was super fast 1-2 seconds. The next day though it had reverted to the previous slow times and I never had those fast times ever again.

Maybe ill investigate again sometime but will use Microsoft ProcMon think its your best bet to find out exactly what its doing when it hangs. If you dont know ProcMon check it out!

 

Sadly I'd say this is not just for large projects. Running on AMD Ryzen 3900x (12core), 64GB RAM, 4GB/s NVMe, and using the Editor Iteration Profiler it takes me 6.5 seconds on one line code change in an empty project that literally only has one small code asset in it.

A completely empty project with one `Foo.cs` MonoBehaviour with nothing in it takes 4.5s for me to recompile after I just add an empty line. It's been years since we've been raising this issue, but nobody at Unity seems to care about actually fixing it. What I find insane that after years of begging we finally got the Editor Iteration Profiler, which now without question shows Unity exactly what takes how long, yet even over a year after it's been released it still takes _insane_ amounts of time for code reloads.

And this is on actually decent hardware, I regularly see people just stare at their Unity progress bar for over a minute after tiny code changes on a small project.

I would understand this happening if something non-trivial actually changed in the codebase, a big asset was imported, or literally anything of significance. But I don't see any reason at all why a single line code change in a codebase with separate assemblies would take 30-60 seconds to reload in a simple 2d puzzle game, especially when it takes <1s to actually compile the C# part.

But like you said, all we get is complete silence. Over the years Unity keeps pretending they work on the issue, yet people continuously post benchmarks showing it's getting worse, and those never get a proper response.

I would love nothing more than to throw subscription money at Unity and build amazing games in it again, but after 7+ years I literally can't use it anymore. I'm not going to spend more time looking at a progress bar than I spend actually building the game, and I'm not alone.

I understand that especially after the cancellation of Gigaya there's probably zero interest at Unity at making the editor usable, because they internally don't need it to be usable. But I'd hope there's at least some last bit of hope that Unity actually cares about the developers and wants to save their platform before everyone leaves.

Nobody in this thread cares about any of the new features nobody asked for, all we want is that one line code change doesn't lead to a minute wait time. Clearly it was possible for this to be fast before, and it's not like Unity gained some new amazing capabilities that require this to be so slow.

edit: Just in case someone from Unity is actually reading this and isn't aware of the past years of discussion around this of people posting benchmarks, I literally just tried 2019.3.15f1 and it is significantly faster even on an empty project. I don't have any big project on 2019.x anymore so I can't do a comparison, but there's tons and tons of benchmarks people posting over the years with detailed numbers.

Really all we're asking for is some accountability on this issue, and share some actual progress. It's clearly obvious that everyone in here is experiencing the issue. There is an issue. It's not a "something that happens in some case", as it was already closed off multiple times on the issue tracker. It happens in every single project, even small/empty projects, and gets exponentially worse as the projects grow.

edit2: Just to double-clarify for Unity people, I did the usual things like everyone else who spent an insane amount of time already looking into it, that is: no antivirus (excluded the whole folder where I have all my dev stuff), new windows (tried both on 10 and 11 and on a second desktop), using a new empty project, across multiple Unity versions, and having been trying this for years across at least 10 different games. It's not something random ad-hoc that's just on my system, or just on any single person's system, as we've been told many times before.

 

These are the times that I'm experiencing...