Official Improving iteration time on C# script changes

2022.1.0f1 runs the worst for me in terms of iteration time.

Domain reload and some weird repaint events afterwards easily add up to 5-7 seconds for script changes at the beginning of development (large projects can be worse)

 

Here's a layperson's idea for domain reload:

Keep two domains in memory.

Main Domain: The one we know and love.

Partial Domain: The other one excludes everything that the user selects in Project Settings as their hot editing path (and by default, it just excludes Assembly-Csharp). It will serve as a bootstrap point for the majority of expected domain reloads.

Now whenever you reload the domain (recompile comes to mind), if nothing changed in Assemblies last loaded in the backup domain, copy that domain (like, literal memcpy), activate it as the new Main Domain, and then only load the handful of previously excluded, user selected Assemblies into the new copy and hopefully be long done before the "Hold On" pops up.

Yes, this is a bit of a brutish suggestion, but RAM is cheap, time is not.

 

I don't think it would work that easily, until something like that would work, in the meantime the runtime has been replaced with .NET 6+ and the domain no longer exists. All the work would be for nothing.
The question would rather be, if no assemblies were actually changed when compiling, would a domain reload be necessary at all? In most cases, when recompiled, something changes, except for reformatting/documentation changes.

 

This. I think it would be great if engineers from Unity can enlighten us why all domains need to be reloaded and all assets reimported if I just change one line of code in my assembly (AssemblySharp).

I think what is the most unacceptable to most users in this thread is that changing one tiny bit of code results in a minute of "Reload Script Assemblies" time. If I wrote game logic code for 6 hours and it is time to finally test it in Play Mode, from a developer's perspective, I can accept longer compilation & reloading times. I might as well grab a coffee while Unity is busy working on it. But the painful bit is when there is a small oversight in your code (that usually involve changing only a few lines of code) and you have to sit through the minutes-long "Reload Script Assemblies" each time.

Yes, Unity is getting much more complex and we have 100 useful new features. But those features should not come at the cost of sacrificing the basic rapid iteration experience. People, especially indie developers, loved Unity because we used to iterate fast. We can grab a few assets from the asset store, write some code, and then put together a gameplay demo in a few hours. That is no longer possible in the later versions of Unity. If I need to wait 5 seconds, sure. 15 seconds, okay-ish. But anymore than that? I will start browsing Twitter or whatever. Then when I realized Unity is ready, I might have forgotten what I wanted to test. Context switching is expensive.

In fact, I hate iteration times in Unity so much that I have completely given up on any UI solutions in Unity and wrote my application's UI in TypeScript + Vue.js, which talks to Unity (it only serves as a renderer) via WebSocket. If you have ever wondered why the JavaScript ecosystem is now so damn popular, it is exactly because of how fast you can iterate with JavaScript. You save the code or change one line of CSS, and your browser hot-reloads the page (or even just hot-reloads a component on that page) and you get to view your results immediately. I don't know what user scenarios did Unity executives or PMs envisioned in the recent years, but this post (and many others on the same topic in this forum) should hopefully let you know that rapid iteration is the uttermost top priority for many, many of us, and is even the only reason why we picked Unity instead of Unreal or Bevy in the very first place.

Please, allocate more engineering effort into solving this issue, and I am sure it will award your KPIs.

 

""on completely empty project " --disclaimer

 

Iteration time is their top priority atm.
Unity is also moving to the CoreCLR backend (.net5 onward), in which there will be no more domain reloading, hopefully.

src: Unity and .NET, what’s next? | Unity Blog
2024 is a bit long, but they can still improve iteration time by optimizing other things in the meantime as they've already done in the 2022 build.

 

I'd rather have double memory usage and speedy domains NOW instead of experimental .NET 6 support in 2024.

I went back to 2020.3 to work on another project and omg it is SO MUCH BETTER. And i remember back when 2020 was considered slow...

 

I must resist posting a satirical meme here poking fun at Unity for (potentially) taking five years to fix an absolutely critical issue. That said, there is a correlation between product usability and revenue, which in turn drives share price.

 

You have to see it realistically, how long would it take to implement something like this, if it's even possible. I don't think this is trivial.
First, resources will probably have to be withdrawn from the team doing the .NET upgrade, which would then push modern .NET even further into the future.
The time it takes for something like this to be implemented and tested can certainly take 1-2 years.
And in the end the work would be for nothing because .NET 6+ changes everything again.
You would only invest months or years for something that would ultimately only be an interim solution.

And the question is whether that would be faster at all. With a memory copy, you would first have to track all references and then map them to the new memory addresses. Presumably, a domain reload here is simply faster and clean and less error-prone.

 

Bullshit. What proves it? A Blog post?

They also said it was a top priority a couple of years ago and it has continued getting worse. In fact they weren’t even benchmarking it until recently.

 

TBF, I found out about iteration time improvements from one of Unity's dev Twitter and 2022's changelog first. I never trust Unity blog posts, but it's clear from other sources that they are trying.

 

I seem to be seeing a trend here. I apologize if I'm oversimplifying, but if the refresh process is being triggered by an event, then is it possible that it's being triggered multiple times? That would explain why turning off directory monitoring makes the whole process faster for some people(@Innovine). That would also explain the duplicated effort that @stonstad showed with the profiler. If the multiple triggering is happening fast enough, it might dodge any mutexes or other guards against such behavior. Beware - I know by bitter experience that tracking down something like that is notoriously hard, which could explain why UT is having such a hard time finding it.

 

I sometimes still get the "Reload Script Assemblies" taking over a minute, but restarting Unity seems to get rid of it again for a while.
This piece of S*** engine does nothing to make my life easier. I will be moving to UE when this project is done.

 

In their "Unity and .NET, what’s next?" GDC talk they mention plans to support edit-and-continue. That'd really be awesome.

 

I get the feeling that's a couple of years away! You can do it right now but it's a real pain to bother with.

 

Yes, I realize it's going to take a while, but it's nice that "proper" .net support is planned.
I have experimented with putting a bunch of scripts into their own assembly a few Unity versions back, so I could recompile them even while the game is running. It's awesome but a pain to maintain. Hopefully that will become a supported feature at some point in the future.

 

Yeah I really want it! In fact I always wanted it but the workload was just not worth the payoff. Added to that (in DOTS land at least), play mode changes will persist. That'll come for 1.0+ I think, so we'll basically be coding and developing on a live runtime, which is really weird but fantastic for iteration time.

 

Unity urgently needs to get their heads out of their backends and get their priorities straight towards developers.

Ever since the company went public, there's been a trend to cater towards wall-street type investor figures (with eye candy features and ever more bloated specialty features) instead of working for and with their end users, that is, the same people with the technical minds who can make those features happen in practice.

The result appears to be more and more that billions of dollars are dumped down the toilet every year as developers all around the world spend half their day waiting on progress bars. This is absolutely unacceptable.

Platforms like unity have an implicit commitment relationship with any team that opts to use it. The notion of "use a different tool" cannot be argued as a viable workaround as you'd normally expect, the amount of work required for the switch is quite easily a bankruptcy scenario for an indie developer.

This isn't a consumer rights issue so much as an industry-wide state of impairment. We cannot wait two years for a "maybe" fix. This has to be addressed ASAP above all else, as many of us are in risk of our small businesses being ruined with no recourse to any practical solution. While iteration times are so absurdly slow that it significantly affects our final products quality and capability to provide player's with decent support.

We quite literally cannot afford to wait for a fix. Careers hang in the balance here. Not OK.

 

Currently using 2021.2.0f1
I am experiencing a 4-5 second lag when turning GameObjects on/off.
I mean, seriously...

Bring back Unity 4 .
It was SO much better.

 

That "seriously" has to be usercode that's running in that case, since that is not normal...
Note that at very least OnValidate is called.

 

Unity urgently needs to get their
***Reload Script Assemblies***
heads out of their backends and get their priorities straight towards developers.

Ever since the company went public, there's been a
***Reload Script Assemblies***
trend to cater towards wall-street type investor figures (with eye candy features and ever more bloated specialty features) instead of working for and with their end users, that is, the
***Reload Script Assemblies***
same people with the technical minds who can make those features happen in practice.

The result
***Reload Script Assemblies***
appears to be more and more that billions of
***Reload Script Assemblies***
dollars are dumped down the toilet every year as developers all around the world spend half their day waiting on progress bars. This is
***Reload Script Assemblies***
absolutely unacceptable.

Platforms like unity have an implicit
***Reload Script Assemblies***
commitment relationship with any team that opts to use it. The notion of "use a different tool" cannot be argued
***Reload Script Assemblies***
as a viable workaround as you'd normally expect, the amount of
***Reload Script Assemblies***
work required for the switch is quite easily a bankruptcy scenario for an indie developer.

This isn't a
***Reload Script Assemblies***
consumer rights issue so much as an industry-wide state of impairment. We cannot wait two years for a "maybe" fix. This has to be addressed ASAP above all else, as many of us
***Reload Script Assemblies***
are in risk of our small businesses being ruined with no recourse to any practical solution. While iteration times are so absurdly
***Reload Script Assemblies***
slow that it significantly affects our final products quality and capability to provide player's with decent support.

We quite
***Reload Script Assemblies***
literally cannot afford to wait for a fix. Careers hang in the balance here. Not OK
***Reload Script Assemblies***

 

Ehm.. lol, ok dude.

 

This engine is dying a slow death, looks like we have no other choice but to switch to another engine.
The editor itself has become a handicap, it's impossible to get anything done without a massive delay.

 

Jeez guys let's chill a bit on all the doom and gloom.

 

Hard to stay chill when this has been the state of affair for more than 2 years with no noticeable improvements so many engine updates later.

 

Yeah, I cant help but feel like this aswell. I see it in many areas, from multiplayer to editor performance. Lack of direction produces bloated software. Sad.

 

Does anyone here use the paid versions of Unity? I get the feeling there is a difference, although can't find anything on it. Eg. are there analytics going on that we can't switch off in the free version (I remember there was on option somewhere before for Editor Analytics greyed out). If I could turn off all background trackers and loggers, I think that it might make a big difference. Think how slow Debug.Log is, well this is happening all the time in the background for most actions.

 

I remember once, I think it was 2022.1 first time installing beta version, it was incredibly fast I thought Unity had fixed it finally. I loaded it up a few times to test, tried a few things, and yes incredibly fast on most things. But get this, the next day, it was back to the slow times dealt with previously. So I don't know what happened between that day and the day after, but something changed about the editor, nothing I installed or changed, I simply opened it the next day. And I never got those speeds ever again on other installations. I suppose a real test might be to completely uninstall it from my PC, and try fresh from nothing. But my thought was that some supplementary part is installed into the editor from Unity after you run it, maybe for analytics. While I don't mind that really, sharing, if it's slowing the hell out of the Editor there should be an options to switch it off. But this is just a theory, based on, nothing comes for free!

 

I'm paid and iteration performance is equally bad.

 

Cant imagine a couple of analytics worsening the performance that much.
Tried Godot for 2d with c#. It's much better for us. I advise everyone here to try it out, and if unity loses some users to godot or other engines, they might tighten their belts.

 

I gave Godot a try a while back. It's definitely a solid engine slowly coming into it's own, but I swear to god it gave me the worst luck. Every other time I opened a project it would appear completely empty and only after about a minute would everything load in. There was no progress bar, no indicator of any loading, no input lockout, just crossing fingers that it would eventually come in this time.

 

Putting my hat into the ring to voice my support for this issue.

This is my #1 wish for Unity.
Please, focus on usability! Please benchmark the editor's performance on a real-world project.

The C# iteration times kill productivity, halting it to a crawl.

 

I'd say benchmark it on an empty project, that's the baseline. I've thought my computer is the issue, although it handles most software fine. I've seen people saying they have the latest computers and having the same issue, so assume it's not a computer issue.

 

2022.1 here - assmebly defs for my code, yet slightest change in the scripts and 15-17s waiting... every freakin' time...

 

I can't quite
***Reload Script Assemblies***
understand why
***Reload Script Assemblies***
three years ago
***Reload Script Assemblies***
it was possible to have
***Reload Script Assemblies***
seemingly instantaneous or at least background
***Reload Script Assemblies***
script compilation,
***Reload Script Assemblies***
but now that Unity has been
***Reload Script Assemblies***
"improved"
***Reload Script Assemblies***
its become
***Reload Script Assemblies***
incredibly
***Reload Script Assemblies***
awful to use.

 

I'm also a bit annoyed at the increased reload script assemblies time and look forward to getting them reduced. Still, I'm very happy for the new additions in the newer Unity versions and consider some (not all) of the extra time a worthy tradeoff. Some of the new features are actually vital for us to continue using Unity, and stuff like moving more code to C# means we get easier and better access to Unity source code, making it more convenient to develop and diagnose issues. I also believe that they'll be able to fix this in the end, similar to how (at least we) have seen a reduction in the number of random crashes in the newer versions, which was something we really struggled with from 2019.4 and 2020 versions.
I assume that those of you who struggle a lot with this have profiled the script assemblies reload times and ensured that there's nothing you can do on your side?

 

It reloads assembly when exiting / entering play mode w/o any changes to the code or scene structure.... What I am supposed to profile here?

Having said all of that Unity does GETS BETTER w/ every update. This is a much more efficient and feature rich editor to work w/ comparing to late 2019 when I begun a project. Not to mention HDRP which over this time gained much more maturity.

Have a few friends, doing large project w/ Unreal, and all PR BS about UE5 aside, you would be really surprised w/ how many things they're struggling there, to get them up and running, which in Unity you just have for granted.

C'mon Unity - you got ray-tracing there, you got tools in place to open up your business further than just a gaming - let's bump up priority on fixing assembly domain reloading non-sense now!

 

Have you looked into this? https://forum.unity.com/threads/any...pt-assembly-reload-time.1117138/#post-7235969
It gives quite detailed logs of what happens when reloading assemblies, how much time classes use, etc.

 

Just wanted to say that for me, with a fresh install of Unity 2022.1.4f1 and a project with one small script, total time for recompile/reload script assemblies following a script change is around 2 seconds.

I'm in the progress of migrating a much larger project (size on disk around 38 GB) from Unity 2021 to 2022, and that project usually takes around 6-7 seconds for recompile/reload script assemblies in Unity 2021.3.0f1, following script changes.

I'll compare that with Unity 2022 once the migration is substantially complete.

 

Looking through logs in this case is waste of time, since we do not have any means to control this process. Unfortunately it goes beyond obvious steps like: remove unused addons, create assembly defs to split up compilation, etc.

I believe they just run this reloading chain before certain events, regardless if anything meaningful changed or not. As more, and more functionality come in, more packages and code is being incorporated, time accumulates here to the level of utter annoyance.

For example: we have an option to enforce domains reload before enter play mode (project prefs I believe). Great. I thought that if I check that, it will limit number of reloads, related to my code (no Editor code there), so that it will do it just before entering play mode.

Nope - it reloads assemblies on his own, and then again, before entering play mode, because I checked it...What the fudge?

I changed a struct definition in a lonely c# file, I have assembly def there, I did not touch Editor code, I did not touch other packages code, why do you - Dear Unity - reload EVERYTHING, EACH TIME?

(rant mode off)

 

If you turn on the "Enter Play Mode Options" option and then also turn on "Reload Domain" then you basically have the same default behavior as before. You have to deactivate "Reload Domain", then you only have domain reload when compiling.

 

Great, but this does not work - Unity will force domain reload anyway: after compilation, between Play Enter / Play Exit. If you check this setting it will reload it again.

 

Domain Reload (DR) and Script Assemblies Reload (SAR) are two different things I still don't get why the former keeps getting brought up when we talk about iteration time since it should be obvious that everyone should've disabled DR the moment the option was introduced in 2019 beta, at least I did.
Now the problem is the Script Assemblies Reload which makes testing any code change no matter how benign such a painful experience that often makes me apprehend having to iterate...

Some ppl claim 2019 was clean, NO it isn't. The only diff is that back then you the loading bar doesn't say SAR but says something like "importing" or w/e but the wait time is the SAME. I made 3 different copies of my entire proj and backported one in 2019 LTS and the other on 2020.2 (before the SAR issue was added to the bug tracker) and I had NO gain whatsoever, it was a complete waste of time and nerves (so much for users online advices...).
The 3rd one was in 2022.1.5f1 and there again 0 gain.
The only thing that alleviated the SAR was removing most of the 3rd party systems in my Plugins folder and even then I can't get past 7 seconds of compile+reload and that doesn't even account for enter/exit playmode.

Now I intend on making 2 different versions of my project, a minimalistic one with minimal scenes & plugins for faster iterations on my user code alone and the other being the main build with 3rd level design plugins (which are some of the big offenders for SAR) and all the 3rd party systems (yes the word 3rd party comes across often because Unity doesn't provide enough satisfying tools out of the box for serious sizable 3D projects and they know it).
Now will that work smoothly enough ? well I will test and see cuz for more than 2 years now we have no other way of improving this situation anyway.
Slow iteration time leads to less unit testing leading to more hard bugs and longer development time for any added feature or debugging.

Is it not possible to give us a toggle to disable even if partly the whole SAR process like they did for Domain Reload and let us handle a small price to pay like resetting static members when disabling DR?
Having an iteration time of < 5 secs (compile+ enter/exit playmode included) would be worth more than any possible feature they can add to the engine rn.
Thank you for your efforts towards this crippling issue.

 

Thank you for saying what I was thinking @StellarVeil
Please let me know how the minimalist project works for you, I have been thinking of doing something similar.

I too wish people would stop mentioning the Domain Reload skip function—of course we are all using that speedup feature already. We are talking about C# script iteration time.

I would do anything to get faster C# script iteration time. Even if it meant jumping through a million hoops refactoring my project, and resetting fields or whatever. I would spend the time refactoring to fit whatever arcane solution if it meant we could make the game faster. Yes, I have tried Assembly Definitions and unfortunately they do not help this issue. Many other devs have the same experience with asmdefs—they barely help. They might even hurt in some circumstances.

Thanks to the Unity devs who are listening in this thread--please know that we are open to many different solutions here and are willing to put in the work on our end. For example, if asmdefs DID work to get C# iteration times to under 5sec, I would be a happy dev and you wouldn't hear a peep from me.

 

Are you sure it looks like this?


In my small project, with 2021 LTS and URP, I need less than a second to enter playmode.
After compiling, the domain is always reloaded, otherwise you would still be running an old version of the code.

 

Has anyone compared the C# Iteration Times comparing 2022 to 2021 or 2020?

I am thinking of upgrading to 2022 to fix some bugs that exist in 2021 and 2020. Sadly they won't be backported.

Anybody benchmarked performance for C# Iteration Time (edit C# script ->wait-> enter play mode) of 2022 in their real-world project?

 

Script Asm Reload (SAR) is the same or slightly longer in 2022.1 compared to 2020 in my many tests.
Enter playmode was ~100ms faster in 2022.1 comp to 2020 on a minimalistic scene with no environment but had most of my codebase active in it (didn't duplicate the full proj's graphic assets to test a big scene due to the long import time and cuz I'm mostly bothered by the SAR right now).

Today I tested the 2022.2.17 alpha and it looks they finally started implementing/releasing a build that addresses and changes how recompile is handled which looks quite promising and cheerful news to me. I noticed up to ~1.3s faster SAR but I wasn't able to get my minimalistic version of my proj to work on the alpha for some reason (my scripts were disabled on my prefabs for some reason probably cuz it isn't the full proj so there are things lacking despite it working on 2022.1.5f) so be careful when you upgrade make sure you make a full backup first.

Tomorrow I'll try to upgrade a copy of my full proj to the alpha version and test both SAR (where I might see bigger benefit than on the minimalistic proj that had less plugins) & enter play mode on the real-world project and post my results.

 

I have to specify that the 1.3~1.7s gain in SAR on the 2022.2 alpha version I mentioned was in comparison to the 2022.1.5f1 version.
Note1: When I say "gain" throughout my post I mean faster.
For reference I'm working on a AA ARPG, with the number of code files probably and easily exceeding 1000 most of which is 3rd party with everything in separate assemblies (which didn't significantly help in speed).
My own code which is the one I change most of the time consists of only about 186 cs files currently (the less the better).

Now the results for the full project:
When comparing my full project in 2022.2a to 2020.3.15f2 LTS there's no difference in SAR BUT if you go to Project settings > Player > disable Roslyn analyzers I gained up to speed up of 1.6s in SAR time for a total avg of ~7.7s. A rather obscure lil trick and it is enabled by default when you create a new proj.
Edit warning: disabling it makes all Monobehaviour scripts unusable in 2022.2.0a ! it seems an issue proper to that version and I'm submitting a bug report.

What's interesting is that that time is reduced by 1 second on an empty scene (~6.7s) where there again having disabled Roslyn resulted in a ~0.5s gain.

Enter play mode gain on a 1024x1024 terrain full of vegetation, some props, characters etc:

• 0,985s faster on first time
• 0,57s faster when scene reload is disabled
• 0,872s faster when scene reload is enabled.

So concerning SAR I used to have ~17s on Unity 2020.3.15 LTS and sometimes ~34s which was a great pain to iterate with so I spent weeks experimenting & researching until I took it down to ~9.3s by removing unused 3rd party plugins/systems mainly the level design ones had more impact and removed Terrain Tools & Recorder native packages.
Now I made a copy and upgraded to 2022.2a and it went from ~9.3s to ~7.7s and I'll try some tricks with asmdef files and conditional compile to try exclude non-critical 3rd party code without having to remove them from the proj.
Note2: sometimes by restarting the editor you can gain a lil bit in SAR/enter playmode times.

The problem I noticed with SAR by looking at the profiler is that Unity reloads your dependencies/3rd party when you change your own code even though they don't reference your code so if it were the other way around I'd understand but not so much when the reloaded parts neither changed nor reference the changing code.
I'd still encourage other users to do some tests so we can have a wider sample pool.

Note3: Trying to upgrade my proj whether it be from 2020 LTS or 2022.1 to 2022.2a always failed with crashes.
The only way I was able to properly upgrade was by making a new 2022.2a proj then pasting only my Assets and UserSettings folders & few proj setting files, this time I didn't paste the Library and to my surprise the new generated one is only 11.9 GB down from the previously 30,5 GB and didn't take forever to generate which was the reason why I used to copy/paste the Library folder when trying other versions.

 

It seems the project isn't working cuz I'm getting the "No MonoBehaviour scripts in file..." warning on almost every Mono file even new ones, any ideas what can cause this ? I didn't have this issue on 2022.1.5f and prior.

Edit: found the culprit ! it's disabling the Roslyn analyzers for some reason causes this issue even on new empty projects ! Which means any gain on the SAR time is now void...
I submitted a bug report, will post the tracker link if it gets validated.

 

Well it looks like they haven't noticed the bug report for something that negates what they worked hard on to produce an iteration speed benefit. Idk how we can bring attention to this issue so I started a thread, if someone from UT sees this please forward:
Bug - (IN-8232) Disabling Roslyn analyzers makes all MonoBehaviours unusable in Unity 2022.2.0a17