Official Improving iteration time on C# script changes

Yeah, personally i just gave up. Unity 2019 does a great job for everything i am doing. But i think the silence of complaints is really just acceptance that nothing will change. At least from my side

 

Same... do all my coding work in 2019... can't stand what's going on in terms of iteration punishment in all versions since.

There's no excuse for this on a m2 Max, where 2019 is running in Rosetta, but still 3x to 10x faster for entering Play mode than the ported native, newer Unity versions.

 

Yeah, but if the only version of a product that works is the version that isn't even in LTS any more... The product might as well be dead.

 

I get the feeling that this is true, for a lot of people who've finished their last game with Unity and moved on, and that many of us that remain our finishing our last game with Unity before doing the same.

 

Just so you guys know for play mode iteration, start getting accustomed to having Fast Play Mode (Disable Domain Reload in Projects > Editor > Enter Play Mode Settings) because Unity is from now on only going to support it!
(Reason: They are changing the GC to CoreCLR)

As bad as this sounds it's actually quite easy to have every static field get reset...
And it is *way* quicker!

But without using this feature, iteration time is a joke, so yeah...

 

That only helps when pressing Play, not when changing code. It's an entirely different subject.

And setting it as default sounds like a recipe for disaster and difficult-to-diagnose bugs for newcomers.

 

After a few months of fighting with Unity to keep it reasonably productive, I started deleting every Asset store module except for the one's made by Unity. It helped quite a bit. But unfortunately that means all Asset store assets have trash quality and Unity has no measures on keeping Asset Store asset quality.

So the choice is either you lose feature productivity by not using some great productivity improving Assets or You lose compile time productivity.

At least its a lose lose scenario yay!

 

Assets not the problem on this topic. The real problem is old mono architecture that have snail slow domain reload.
Also compile time is not the issue, it nearly takes 1 sec on moderate projects with bunch of plugins. real issue is here domain reload. Also you don't have to make guesses, just open the profiler, switch to editor mode and deep profile and profile a script change. With that you can see how different elements contribute to iteration time
(specially new input system, SRPs and visual scripting).

 

And Burst. Much as I love Burst, I have to remove it to get work done.

 

While true, there simply has to be something afoot in their specific project or PC specs when people say that recompile takes 40s despite even using asmdfs!
It is not the case for so many others...

It is something you need to know/learn. The initial values you set for static variables simply do not need to be what you get when the game runs. That is similar with all public and [SerializableField] variables of MonoBehaviors where you have changed the default value in the scene or prefab.

In case you did not know, you can add the "Jobs" package that adds a few extra options, among which to just disable burst compilation (while you work in the editor). Then there's no impact from that anymore (and since it is an asmdf package, there's no additional recompile time from the package being in the project).

Edit: Or are you saying the Burst package on its own actually adds significant time?
Then I fear you gotta get a new computer :/ Burst is something I add immediately in every project and I have <5s iteration time (with disabled scene reload) until adding massive other things (on an already 'old' 3900X) in 2021 and 2022.

 

You live in a different universe, code monkey. This hasn't been how asmdf packages work for the vast majority of users.

Just adding Burst to the project, and not yet using it... 3x to 10x blow outs in entering play mode time.... and big changes to build times.

All your other presumptions are wrong, and experiences different from everyone else. I'm happy for you, but please understand that there's no existing solutions for many, and that Unity really does need to go back to working on the compile time issues, and no amount of placation by you makes their experiences better.

 

Lol, you know it's more like a great praise to be associated with the possibly most famous active Unity youtuber?

This is literally not what I am experiencing. At. All.
I'd suggest to try on a different computer.

It is a minority which has those strange issues. Maybe it is even related to some OS configurations, antivir software etc.
Unity just got voted as the best engine for mobile games: https://www.pocketgamer.biz/mga2023/winners/best-game-engine-platform/
Wouldn't be the case if "everybody" would be struggling.

 

The people in this thread are seeking answers, not sycophancy and braggadocio.

 

Answers have been given. By Unity staff as well as community.

 

The answers given by the community don't work for many users. And the last message from Unity was "we're still working on it".

Seriously, we're here for a reason. If you're just going to be obtuse and combative, find a new thread.

 

Yes, you're here for venting. Otherwise you would measure (profile) whatever is not working for you and would submit bug reports so Unity actually can see what's your problem instead of lamenting how 2019 was a good year and how many users in your heads are switching to unreal.

 

But what is it that you want to hear?
Unity is working on integrating a whole ass runtime (CoreCLR), meaning of course it’s gonna take a long time!

Tbh I also want it for the wait to end, but a quality product requires some quality time.

If you don’t like it switch to another one!
Like we devs should be accustomed to switching frameworks and stuff… This is literally the same!

Unity is currently in its “WIP” stage while other engines are currently in the spotlight!
When Unity becomes good again switch back!

 

Since... ?

Estimated time of arrival?

 

2020

They can’t disclose this… (They don’t want the same thing with DOTS to happen again XD)

 

You know that we know that it's the packages, the newer Editor, new new stuff and whatever's going on with the DOTS inclusions and new shaders... and that most are driven to working in old versions without these, with a bare minimum of packages, to get things done on the daily whilst waiting for some signs of life, care and love from the core of "new" Unity, right?

And that the CTO that championed all the ECS migrations, SRP etc... is on a sabbatical...

 

But it is happening - with SRP, The New Input System, the Visual Scripting system, the wait for an Animation System, the UI Toolkit/Builder not being anywhere near the capabilities of UGUI, light baking, etc etc...

But Burst is finished, and Jobs are good. If you don't mind having time to make a coffee and shop for, then cook and eat lunch each time you hit build.

And so long as you don't mind the previous systems atrophying without any attention during this unknown WIP session...

 

Oh I forgot people at Unity should be slaves and not allowed to go on vacation and away from work... seems legit and absolutely not looks like that you're here for venting.

 

Seeking and sharing solace, solutions and insight, actually. Your purpose?

 

Ok guys chill, let’s de escalate!
Unity is definitely being slow on change…
Especially when Godot can be quicker to adopt the latest .NET technologies…

Seriously though, Unity has probably become too old hanging on to its old framework and it shows!
Either for us the users or the Unity Devs themselves!

They should reconsider a total overhaul => remake of the engine imho…
Would probably be faster at this point!

 

Or just Burstify and Jobify all the old systems so that we can at least use multiple cores on mobile and push as much as we want off the main core, increase frame rates, lower battery usage etc...

Then we could at least feel good about getting the most from our player's hardware with the functioning and effective existing systems whilst we wait...

 

I'm listening to Thomas Brush over the GameDevGuild stream and apparently I'm also poking the proverbial unwashed hobo bear who is struggling with PTSD, depression and on the constant edge of a nervous breakdown.

They are constantly understaffed, they can't push out enough changes to feed your appetite. Why on Earth do you think they should take on a massive task to recreate the entire ecosystem from scratch? You should really think this through because this idea isn't really feasible not even remotely.

 

Because I think it has become a case of “their own legacy code is hindering them”

 

argh... yes, the lurking part of the name.

Yet this is DOTS...

5000 staff, still? And that's not enough? Perhaps they need a ninja willing to give up his penchant for lurking around game dev to actually do some dev work.

 

I think this "5000 staff" was a typo that became like a virus somehow, It could be 500 or something .

Anyway, we would like to know how many developers are working on unity, and I literally mean the people who write the code.

 

According to Unity's LinkedIn profile, they have between 5,001 and 10,000 employees. You can check it out for yourself at https://www.linkedin.com/company/unity

 

Speaking of which I just finished profiling editor iteration time for Unity 2021.3.15 and 2023.2.0a12 using my current work project and script compilation time was lower for the alpha than the LTS. I'm just not seeing the performance problems people are having with my own projects.

https://forum.unity.com/threads/changing-editor-scripts-is-so-slow.1430890/#post-8986258
https://github.com/Unity-Technologies/com.unity.editoriterationprofiler

 

As someone with a project that needs ~30 seconds for compile + domain reload on Unity 2022.2.14 I also checked the editor iteration profiler, but I'm not really seeing anything on my end that I could change to speed things up.
Compilation takes about 15 seconds, most of that is waiting for some task (probably compiler?) and regexes parsing the compiler output.
AssetDatabase V2 "importing out of date assets" is 8 seconds but most of that seems to be reflection for the domain reload and re-awakening editor UI classes.
The remaining time is stuff like building the assembly graph and assembly reloading.
Generally in all areas a lot of time seems to go into string manipulations - comparisons, building file paths, parsing.
None of this seems like something that I could influence somehow other than "have less code to compile", but then again I have a different project with a lot more code on Unity 2019 that needs ~5 seconds for all of this.

There is ~1 second for Burst stuff which seems potentially unnecessary because I have Burst compilation turned off.

Already had sent the project to Unity for someone to look at last year which might have led to some improvements (used to take ~45 seconds).

 

What worked for me (after everything else didn't) was deleting the Library folder. Close Unity. Delete the library folder in your project. Open Unity. Unity will rebuild the library folder (make yourself a sandwich, it'll take a while). After that, my compile times dropped from 30-40 seconds down to less than 5.

This is now a weekly thing I do on my projects.

 

Compile time or domain reload time?

 

Overall build time after a change is made in a C# script and the editor regains focus.

 

Can confirm, though in my case it was a minor issue anyways (3 sec) and know it is 2 secs.
But doing this sometimes causes Unity to break... weirdly enough (package cache locks), so if you don't know what you're doing it's going to be a hassle.

Solution: When the popup for the package cache shows up, press retry, no matter how many times it pops up.
In my case sometimes even 5 times needed for it to fix itself!

 

That should probably be reported as a separate bug if it hasn't already. Unity themselves don't suggest putting the Library folder into source control, so regenerating it should be a standard practice when pulling a fresh codebase from a repo.

 

You're right but this issue has been there for over 2 years in LTS... (I know that's crazy)

Anyways, I don't have the Library folder saved in git so yea! You really just have to retry opening the project maybe max 3x and then it's solved forever, so doesn't really bother me you know?

 

asmdfs could be the actual reason it takes so long to recompile, because there is a lot of them, with tons of dependencies, and it becomes multitude times worse when there is a .dll with Auto Reference enabled (EVERY asmdf will reference it, no matter where it is.)

So for me, manually removing all Test assemblies (GOD Unity please, why do I need those... strip them! Oh wait, it actually does...) and combining some packages/asmdef into a single asmdef helped quite a bit with recompilation times. It's a literal waste of time, but also my last resort.

EDIT: As @Spy-Master mentioned, Test assemblies are not included during compilation, thus removing them most probably changes nothing.

Also, ECS 1.0.x makes recompilation times 2-3 times worse, from 15 sec to 45~... And it has 19 Test assemblies in a single package
Some other people complain on Rider integration package 10-20 sec slowdowns (but clearing Library helps).

 

They're already recreating the entire ecosystem with ECS/DOTS, from scratch on C#, while being bounded by legacy game-objects workflow, which led them to spending at least 5 years to come up with convoluted, overengineered and mediocre tech. Time wasted for nothing.
Remember how they used to brag how it takes them so little time to create stuff with ECS? Like "initial Unity Physics is a work of 2 weeks", "MegaCity took us only 2 months", "ECS 1.0 will ship in 2019 with all the missing Core engine features". But they couldn't make it, because it would NEVER work with game-objects. Even if they spend another 5 years it won't work. The new conversion pipeline shows it very clearly that this Editor was never meant for it, and will never be.
CoreCLR and .NET 6 could improve it a lot, but it would still be vastly cancerous.

The Editor UI itself suffers from tons of legacy stuff that is impossible to extend/rewrite, that looks bad and performs extremely slowly. And UI Toolkit fixed nothing, only made it much worse and even slower. (thanks to poorly designed blackbox backend with extreme amounts (talking thousands) of recursive events on every element).

In any case, there is very few experts left at Unity to actually make this stuff happen, it is very unlikely that we'll ever see a brand new Editor designed around ECS. Even if it's the most needed thing for the future of this engine.
Which is just F***ing sad.

 

This sounds odd. Test assemblies shouldn't be considered for compilation at all when properly gated behind UNITY_INCLUDE_TESTS and the containing packages are either embedded or set as testable in the project's package manager manifest. What are some examples of test assemblies that don't follow this pattern?

 

Can't find any info on that, except:

Only mentions player build, not actual re-compilation.

 

Unity docs:
https://docs.unity3d.com/Manual/cus-tests.html#tests
Where it's actually checked in-engine:
https://github.com/Unity-Technologi...criptCompilation/CustomScriptAssembly.cs#L413
The assemblies shouldn't be compiled and produced under Library/ScriptAssemblies unless they fall into one of those categories.

 

Seems about right. Then I must be mistaken, and something else caused such slowdown with Entities when I was setting up the project and test scene. Could be some Library issue (got no idea what causes those, maybe compilation cache/artifacts?).
Also, Reload/Update Scene (that happens on recompile or first load) is drastically slower when dealing with ECS conversion in Sub-Scenes that have few thousand of game-objects (even processes disabled ones for some reason), 15~ sec for 2K~, this happens persistently. Same goes for applying changes to prefab, could take literal minutes to apply a single change for many instances (while it's just a few seconds with regular game-objects).

 

.dlls aren't recompiled during domain reloads though. They should have no substantial effect on domain reloads and haven't in my experience.

 

This looks really strange... back in my days, we wrote to xml files via c functions... at least it was fast.

 

I did a lot of call stack time consideration in Objective-C, which is a slow, try-not-to-fail or "fail gracefully" system. But this is going out to serialised objects, to disk, so bound to be far, far slower.

Can't help wondering what a C based engine would be like, without OOP's inherent messaging cruft.

 

You will die if you look at any of UI Elements recursive callback trees

 

You may have encountered a situation where assemblies (EDIT: asmdefs) have not been set to "Override References" with their dependencies manually specified. If they are not using manual override references, then they automatically reference all of the other auto referenced (EDIT: precompiled) assemblies (EDIT: dll files) included in the project, just like the new scripts that get put in the default (EDIT: predefined) assembly. That means that if a change is made to some other (EDIT: precompiled) assembly, not including the code in the default assembly (EDIT: obviously, as modifying the default CSharp assembly never triggers a recompile of assembly definitions or precompiled assemblies), (which should normally be less common, like upgrading a plugin), then assemblies (EDIT: asmdefs) that were not told to override and only reference their actual dependencies will all recompile just in case that other (EDIT: precompiled) assembly change was relevant to them. Override References disabled is like the alternate side of the Auto Referenced paradigm for (EDIT: precompiled) assemblies. It is disabled by default, so one plugin (EDIT: I should have said assembly definition) automatically references all of the other plugins (EDIT: precompiled assemblies) that say they should be auto referenced (which they should be, set to auto referenced, unless they are like a nested sub assembly that is not actually used publicly, otherwise scripts in the default, predefined assembly can't use them), until you switch on the override and that plugin (EDIT: should have said adsmdef) can stop assuming it might depend on any or all of the other plugins (EDIT: precompiled dll assemblies).

However, if only scripts in the default CSharp assembly change, none of the other assemblies should have to recompile because the dependencies are the other way around. (EDIT: But, it will trigger the entire default, predefined CSharp assembly to recompile, which is a good reason to break out stable submodules into their own assemblies, shrinking the size of the default assembly.)

EDIT 2: My first edits said "predefined" where they should have said "precompiled".

 

Override References has nothing to do with other .asmdefs. It is used to avoid Auto Referenced precompiled plugins / .dlls (which is a problem with some packages, they include Auto Referenced .dlls and don't use Override References, which causes every other .asmdef to reference that .dll)

"By default, all assemblies in your project created with Assembly Definitions automatically reference all precompiled assemblies. These automatic references mean that Unity must recompile all your assemblies when you update any one of the precompiled assemblies, even if the code in the assembly is not used. To avoid this extra overhead, you can override the automatic references and specify references to only those precompiled libraries the assembly actually uses"
Unity - Manual: Assembly Definition properties (unity3d.com)