Official Improving iteration time on C# script changes

I'm on 2021.2.1f1 as well and the issue is TERRIBLE. I'm getting 30 second reloads even on brand new, empty projects, out of the box. It also takes 5-10 minutes to simply open a project, even a new one.

While I am using a somewhat older machine, I was dealing with very brief (2-5s) reloads around 2019 or so. I have even reinstalled my operating system (Win 10) fresh within the past year and the issue with Unity persists.

 

Yes, I noticed this too. The load times in 2021 are really bad.

 

https://mobile.twitter.com/After_The_Cloud/status/1463754371963916292 maybe this helps a bit??

 

Or maybe can give the new Unity 2022 Beta a try. Now if we disable Auto Refresh, it will reload asset when Enter Playmode after changing script. In older version we need to refresh manually if Auto Refresh option is disabled.

 

***If your project is sufficiently large (based on number of scripts, number of assets stored in asset database) ... none of the steps proposed across the five pages of this thread, and 20+ pages of other threads, will achieve editor iteration below 5 seconds. Having literally worked through every optimization proposed here I have no remedy beyond Unity fixing the severe regression in iteration performance. @xoofx***



A year ago iteration was instantaneous.
Now that it has been "improved", every possible action requires lengthy waiting times.
Shifting responsibility to the developer/user to completely rebuild every aspect of their project including all plugins , seems , well, a bit weak.
Maybe instead of spending a billion dollars to buy Weta Digital, Unity could just focus on getting their software to work?
Just sayin'

 

Thank you Unity for your continued efforts. Six months has passed since this thread was created -- do you have an official update you can share? *edit to @Maria_Angelova

Thanks

 

+1

Felt like liking your post wasn't enough so here's a bump: BUMP!

 

helo plz fix

 

Cases like those really have something todo with the particular machine...
I cannot even by far reproduce that on my 3 years old ultrabook mit mobile U-CPU.

 

@simon-ferquel-unity Who is this reply addressed to? Is the performance team and @xoofx still actively working this critical issue? In other words, no one is waiting for telemetry to get this fixed?

 

Simon, I find your post very distressing. I am going to reply back tomorrow in full. In the interim, if you haven't already please read this thread from the beginning.

 

Something is wrong with your hearing then, because I hear:

"Check what's happening, run the diagnostics, if something is fixable by you, do it, if not, send the data with the bug report".

 

did that a year ago https://issuetracker.unity3d.com/issues/increased-reload-time
solution pointed to this thread.
and now?

 

Look, since I don't have access to your bug report (naturally), I have no idea what was truly shared during the submit, but judged based on the available text it is just "look, it's slow, do something". Which is a known issue and Unity stated multiple times that there are things they can do and they are doing it, some things need more time since they need to refactor many things and there are things where they don't know if they can do something because it's simply not happening when and on computers they are trying.
If you read back this thread, there are some tools you can gain more data with, what's happening during importing assets and compiling code, if you run those and get some more information, submit it to Unity so they can identify the problems and they can fix it.
Otherwise, they're working on it with other people who actually can share more details about the problem

If you actually have done that and still got closed, ask for a reopen. Human mistake can happen any time and bugs can get closed without a good reason sometimes.

 

if you start your unity 2021 project with the -noUpm command from the windows commandline, your compile times get a lot better.
Without -noUpm ive got 1 second + more (2.5 sec). turning off the "windows real time protection" speeds that up again by 100ms

-noUmp disables the package manager btw, so be aware!
https://docs.unity3d.com/Manual/EditorCommandLineArguments.html



for comparison, these are my ususal compile times i am having with Unity 2021.3.0f1 the package manager enabled and windows defender on. With 1 Single Script in the project and only the latest visual studio package, default render pipeline:


at the 7 second compilation mark, i also had the infamouse (hold on, reload script assemblies) bar.

in unity 2020 the compile times with both off (-noUpm & no realtime protection), are exactly like in 2021 with both off. 1.3seconds. with both on it wil go a bit over the 2 second mark, so less then what you see in 2021 with both on

in unity 2019 this trick doesent have much of an impact.its 1.4 seconds with both on, and 1.2 seconds with both off

so my observation is:
the package manager

 

One of the major contributing factors to increased domain reload times is the move of more native engine code into managed code in packages. Back in the old Unity days, almost the whole engine was implemented in the native side and only the code in Assets needed to be reloaded. Nowadays, big parts of the rendering stack, input system, UI and other engine components are managed code and contribute to the domain reload time. The amount of managed code in an "empty" Unity project has probably increased by more than an order of magnitude.

-noUpm

is the same as removing all packages. In today's Unity, that means removing half of the engine and that significantly reduces reload times.

And I wouldn't want to go back to an all-native Unity. Being able to update parts of Unity separately, releasing experimental packages earlier, making more of Unity's source available for inspection and editing, or having third-party code in packages instead of in your Assets folder – those are all great improvements that and I don't want to give up.

But this means domain reload times are a trade-off, not an issue with a singular fix. They'll likely never be as quick as they were in old Unity versions. Maybe, with .Net 6+ and a new way of doing domain reloads that Unity is planning together with Microsoft, will we see a general improvement – but that's likely a few years off.

I do want Unity to try their utmost to keep domain reload times down and to find, fix and proactively prevent issues in packages that exacerbate them. But I don't expect any dramatic general improvements anytime soon.

 

The thing that blows my mind, is that this more or less proves that assembly definitions (an advice that is being thrown around a lot, in this thread even) doesn't really work, because otherwise, surely packages wouldn't have such a big impact.

So the short answer is: There is nothing you can do. It's a design decision Unity made. Editor iteration and performance just suck now, just deal with it. Everything Unity is suggesting is a misdirection and passing the blame to the users, while from year to year, these things keep getting worse.

It is what it is. Just keep it in mind when you start your next game.

 

It does not remove packages that are already loaded in the project though, right?
Like it won't break a URP project for example which you could only set up if having the package manager in the first place.

Your explanation is interesting in every case and sounds plausible. Would explain why the dev team can improve small things like what they say to do in 2022 releases, but cannot return to the performance Unity once had in this regard.
It's an unfortunate but perhaps needed trade. Packages are adding nice flexibility and especially editability. I modified the Animation 2D package for example and that would be impossible if it were native.

A few seconds of wait time is fair for that. I usually have unity on another screen. So I code, save, click into the window to trigger reloading and then keep coding or thinking about the code until the reload finishes.
It also forces you to expose settings early in the inspector which is not inherently bad because having constants in code is a bad thing too.
People who have literally multiple minutes of load times should really follow the advice to use the special profiler and post the details/logs. Am not sure I've seen anyone showing that so far.

 

gotta disagree. the long compile times i shared above are the same even without any package in the project.
-noUpm is only giving the speedboost

 

Assembly definitions are good for bringing down compile times. Only assemblies with changed files and its dependent assemblies have to be recompiled. But compilation nowadays is pretty quick, the domain reload is taking most of the time and the it always needs to reload everything, splitting stuff into assemblies doesn't help there at all.

But I still expect Unity to improve reload times and think there's definitely opportunity to do so. They're just small improvements spread over many packages and will be slow to address. I don't expect dramatic improvements but I do expect incremental and continued improvement to reload times.

I believe it does? If you start Unity with

-noUpm

, there will be no packages in the Project window and script referencing any packages will create a compile error.

A quick test from me on Unity 2021.3.0 using the domain reload timings:

Code (CSharp):

1.                      Upm       -noUpm    Change
2. Without packages:    0.646s    0.653s    0.007s (1 C# file and 0 packages)
3. URP template:        1.297s    0.654s   -0.643s (4'768 C# files and 50 packages)
4. Current project:     4.305s    error            (5'933 C# files and 67 packages)

I don't see a change without packages but a 50% decrease with the basic URP template project.

I hope Unity can address the slowdowns you see with UPM but I don't think it's the root cause of the issue discussed here.

 

interesting. whats your CPU?

 

Edited the post above with project stats. This is total files in project folder (including

Library/PackageCache

), as well as packages including dependencies (just a count of the folders in the package cache).

I usually also have a few different tabs open and noticed them appearing in the domain reload timings of my current project. If I switch to the default window layout, it looks like this:

Code (CSharp):

1.                      Many Tabs  Default Layout  Change
2. Current project:     4.305s     3.416s          -0.889s

Apple M1 Max

 

Sure, but they are offered as a solution when people complain about editor iteration.

 

I wish there was an option for potato mode.

 

Just a bit of an update. i managed to get compile times under 1 second (2021.3.0) by:
- noUpm command
- turning off windows real time protection
- added the project folder to Excluded Folders in Windows Indexing Service
- Added same folder to the exclude folder to Windows Antivirus



as soon as i am removing the -noUpm command line command, and add a package like visual studio, compile times go up again and the range is also pretty high. but also without any package, the timer is always aroundthe 2 sec line



not much more info then the previous but i just wanted to be sure if i get the same result on my other windows pc

 

There has to be a simple fix for this. I can't forcefully speed it up anymore, I already have a NVME, intel i9 and 32GB RAM. What would Laptop users do?

I use Assembly Definitions as well, and if I have 4 scripts in one assembly definition, Unity should not take 12+ seconds when I add a Space to my code and hit save.

Yes, the Engine now has more managed Code and I like the progress Unity is making, Shadergraph has come a long way for example. But there has to be a way to separate Plugins from your game logic...

 

The domain reload is taking most of the time and Unity has to reload the whole domain, including all loaded assemblies. This is because in Unity, everything can interact with everything else. Even if code is split between assemblies, one assembly can use the code and objects of other assemblies freely. You cannot just reload part of it, you don't know what parts might, directly or indirectly, rely on it.

Unity could use multiple domains and then reload just the domain the changed script is part of. But that would mean code can no longer directly interact and would have to use a messaging mechanism to communicate, which would e.g. make writing editor code much harder.

12+ seconds on a modern computer is a lot, what operating system are you on and how big is your project?

 

same here. I'm on Unity 2021.1.22f and need over 5 minutes for my project until the editor opens. And that's on my high-end PC. Very terrible. When I close the editor, and reopen my project, then it's faster (10 Seconds). This only happens when my PC starts for the first time or I don't use Unity for a long time.

 

Is that an inherent "issue" of C#?
How comes C++ can just recompile single files and their dependencies to work? o:

 

Both C++ and C# don't even need to recompile dependencies if they are separate assemblies. They can even use newer versions of the dependencies if they are compatible without recompiling anything. But compilation is not the issue here.

Even if compilation was instantaneous, first the previous version of the program must be stopped and its memory must be released, then the new compiled version must be loaded into memory and executed. Also, in order to make it a somewhat seamless experience, the data of the previous program must be serialized before unloading it and then it must be deserialized into the new program.

That's usually even harder to do with C++. C++ doesn't even do JIT. There are some known solutions to hot reload C++ code very quickly, but they require some very specific conditions, and only support very specific code changes that don't change the current data state.

 

I see.. right.. With "in Unity, everything can interact with everything else" Adrian referred to the fact that our custom code must interact with the inspector and all that which makes this approach necessary.
Makes sense.

 

I'm on Win10 Pro, Project is 29Gb (including Library Folder). "Assets Folder" is only 9Gb.
Unity Hub, Unity Installation and the Project are stored on my NVME Disk.

For some reason, it is faster now. I tried the "-noUpm" mentioned above, but obviously that breaks my project. So I removed the parameter and reopened my project, which did some re-importing (took a few minutes).
And now the "reload script assemblies" is a lot faster.

Can somebody (with a long assembly load time) try to delete the Library Folder and see if it's better after Unity re-imported everything? Maybe there is just a lot of garbage piled up?

 

I have spent more than 12 years developing with Unity and it has come to a point where I really have to seriously consider shutting down as the editor performance has just become impossible to work with.
I spend about 7 out of every 8 hours now waiting for Unity to compile or reload something.
It is just not realistic to work with it anymore.
It's so incredibly frustrating. Any remote prospect of work efficiency has gone totally out the window. My productivity has gone down to about 5% of what it was a year ago.

Is there actually anyone at Unity that thinks that this is seriously able to be used by any business?
It's as if none of the Unity dev engineers have ever actually tried using it themselves on any real project.

I am astonished that any company could release software that performs so abysmally.

 

Dear Unity people. Respectfully, its probably a good idea to post an update here on the progress of the mentioned task force that was assigned to sort these issues out.

As Unity moves closer to.NET (finally ), the domain reload issues will likely go away, but having csproj/Core CLR and Nuget is realistically years away.

Thanks

 

Hello!

I'm using Unity 2021.3.0f1 and was experiencing serious slow down issues until I removed some unused packages, and now it's back to normal again. No more 20s 'reload script assemblies' in my small project.

These are the packages I removed:

Visual Scripting
Rider IDE
Visual Studio Code Editor

I also updated Visual Studio Editor to 2.0.15 (I'm using 2022).

Hopefully this might help someone.

 

I agree with @AcidArrow's sentiment. This issue has persisted for the better part of two years and the professional (full-time, employed, studio) engineers have been very vocal about the impact. Not everyone is affected but the many who are have clearly communicated a need for transparency, communication, and urgency.

@simon-ferquel-unity's recent post shows us that Unity staff is requesting telemetry to further diagnose a cause. I find this incredulous, as this issue is over two years old and we have discussed the behavior ad nauseum with supporting telemetry.

With a demonstrated lack of meaningful progress I hypothesize that this outcome is caused by a lack of political and technical will within Unity to fully overcome the issue using current engine architecture. To be clear, resolution of the issue is a full return to sub-second editor iteration time comparable to 2019.x.

I'm a steadfast fan of Unity and its stated goal of democratizing game dev. But, and this is important -- at the end of a day a product must ship. This issue makes it more difficult to ship products on budget and on schedule and as others have suggested, it requires us to evaluate alternatives.

I welcome feedback from the Unity team demonstrating meaningful progress!

 

What I think some people here would prefer or would see as the right approach:
The features, additional code etc. that resulted in this significant increase of time should have been caught at the time they were implemented - and due to their impact, a way to make the features optional might have been a good idea.

On the other hand, I understand from personal experience how a growing project becomes slower and slower. It's very hard to avoid.

Still it feels like something radical needs to be done that's not just pumping man hours into this which are needed in other places too. Perhaps removing the changes from LTS versions until they are fast enough or making them truly modular. Thing is, a main advantage systems based on interpreted languages like C# (but also Python for example) have, is normally fast iteration times (as opposed to engines that require recompilation) and this problem is throwing away that advantage...

That said, it's clearly very project dependent (mine does not suffer that noticeably for example) - size alone isn't the culprit - and thus asking for the logs is surely a good idea.

 

Now thats a Statement!
And honestly a good one since it’s not giving us false hope. Thanks for explaining everything so well

 

@xoofx Thank you for continuing to address our concerns and working to improve the experience.

 

So the tl;dr; is that since Unity decided to move (or invent new) features to C# world, even with much more optimization and greater code quality, and apparently there is considerable effort going towards that, further degradation of editor iteration year over year is simply unavoidable.

I have no idea why Unity thinks it's a good tradeoff.

 

Does this mean that some user found an issue that was not present for you in your small project benchmarks? Or that you do not benchmark small projects at all?

 

Yes, it's great that Unity has so much added functionality and new features.
Unfortunately it is has also now become essentially unusable.
*slow clap*

 

Seems if you want low iteration times you need to:

- Use the oldest Unity version you can get away with.
- Use as few packages as possible: use built-in pipeline, use legacy input, etc.

Remember when C# had much better iteration times than C++?

 

2022.2 alpha 12 has some nice speed improvements! chapeau!

 

The 2022 changes look pretty good. I'm hopeful.
https://twitter.com/s4schoener/status/1525548465626947586