Official Improving iteration time on C# script changes

I just tried the latest 2022.2 beta which has that issue fixed but no improvements whatsoever to iteration time sadly.

 

My experience with a project that is 25GB in size with well over 3000 scripts is that reload script assemblies takes about 2 seconds after hitting play and total time waiting after editing a script is about 4 seconds.

So, for whatever reason, I don't seem to be affected by the same problems that are being reported here.

 

What unity version?

 

Version 2022.1.19.f1

 

I use Jetbrains Rider and found that removing the two visual studio packages (don't need them) made a big difference. As an example, opening Unity on a project took 32 seconds until I removed the visual studio packages. Now 15 seconds. Assets folder size about 2 GB. Transitioning to play from edit mode also improved dramatically. Wild.

System: 12900K @ 5 GHz. 32 GB DDR5/5200 MHz, NVME Samsung 980Pro on MSI Z690 Carbon

I'm wondering if the Visual Studio packages are from Unity or provided by Microsoft.

I've never understood why the Visual Scripting package is a default install. I end up having to remove it every single time. I don't mean to offend anyone (and do not want to derail this valuable thread) but I can't imagine why any experienced dev would use it.

BTW this is on Unity 2022.1.16

 

I guess that's because Visual Scripting is meant to help beginners. It's easier for an experienced dev to uninstall a package, than for a beginner to install one. I think they should instead use the templates UI in the Unity Hub for that, though; they could have a default template with a big title that comes with packages like Visual Scripting.

 

That's interesting, I have a similar specced system but with 3700x but when I changed to NVME 7000mb/s drive I got the time down from 6 seconds odd to 3.5 seconds. Guess it's disk stuff?

Will be getting a very specced out 7950x system in a week or so built, will test on that as well. Hopefully it takes 2 seconds this time but I highly doubt it'll go lower than 2 seconds. Unreal works really well and changes are instantaneous on even mid sized projects so I think it's definitely some architecture problem with Unity

 

What ya doin' Unity? Can't be closed through task manager, it's completely non responsive.

 

https://forum.unity.com/threads/reload-script-assemblies-take-a-long-time.1345607/#post-8498054

On my thread, you'll see that the newly created empty project still maintains a very long reload time.

 

Thank you for the update. It is greatly appreciated.

 

It is sad that the team is lacking resources. Such a core part of the engine should have more resources. Thanks for the update, though. I hope you guys get more resources to fix this.

 

Also apreciated.
Well, in the meantime, everybody get powerful computers, I suppose.

Deadlocks and generally rare multithreading-related bugs are the worst to debug. Big thanks for Burst to exist in Unity against that.

That said, it somehow has to have something to do with the project, because by far not everybody experiences them. (I only vagualy have memories of having had to kill Unity during reload at some point and think that was while I was messing with a custom DLL).

What I'd suggest for someone who is having that problem:
Do bruteforce to ensure reproducability and then shrink down the project step by step until the problem disappears to figure the cause.

By bruteforce I mean write a script outside Unity (python or something) that edits a file in the project to trigger a reload. Then let Unity write into some external file after the domain reload (there are some hooks available for that). That file is watched by the python script so it knows when recompile was successful. Then the python script does an edit again and so on until the reload time is over a threshold which means deadlock or crash occured.

That may take a few hours of work to set up and possibly days to run (with reductions of the project between), but it may solve your problem.

Edit: Using a file as interprocess communication to detect succesful reload could be omitted if you find some cache file which Unity modifies on each reload already. Commit the temp directory to a new repo without gitignore to find that out perhaps.

 

So as I said we just need Unity to migrate to CoreCLR and AOT?
(That's also what they said in the .NET Conference, Ref: The future of .NET in real time 3D applications using Unity | .NET Conf 2022 - YouTube)

 

Ya seems like we were right on this one. I'd be lying if I said I wasn't disappointed, but as long as they stick the landing on this (hopefully relatively soon >_>) then I'll be happy.

 

Also they already have a working prototype of the Standalone Player/Build in CoreCLR which builds super duper fast!

So I'll assume it won't really take that long, to release...
If I had to guess, I would put my bets on 1.5 to 2 years of time until this releases in the latest alpha fully, so with the editor using CoreCLR.
This is actually pretty hype XD

 

It was already mentioned that the standalone player gets a coreCLR option first. a coreCLR based editor later. I think the player version comes with either 2023.1 or 2023.2, editor with 2024.x, or 2025.x. Iteration times will only change with the editor version.
It was also mentioned that the target is only changed to .NET 7+ with the editor version, until then with .NET Standard 2.1

 

Maaaaan in 2 years we'll be at like .NET 9 and C#... 12? I think. Long ways away.

I have to admit it's pretty saddening to hear that the scripting team is so stretched in terms of resources. Joining up with .NET proper is kind of insanely big for the engine.

 

Ten hours, hilarious.

 

This isn't related to the thread.

 

If this occurs somewhat often, try to do what I suggested here please: https://forum.unity.com/threads/imp...c-script-changes.1184446/page-10#post-8591239

 

You could kill the process and restart Unity. Not ideal for sure, but it beats waiting for several minutes (or hours).

 

Not the solution to all issues, but we should give this some attention

https://forum.unity.com/threads/rap...recompile-domain-reload.1361971/#post-8593735

 

Do you mean next year as in after December we'll hear some amazing news or next year as in November 2023?

 

I just left it running to see if it was just lagging and ended up forgetting all about it - it's inpossible to kill it in task manager and when I manually restart it hangs on that like it's trying to kill it but can't so have to hard reset. I do wish I didn't have to deal with this and I need to back up pretty soon.

I've uninstalled everything related to Unity, have reinstalled, but Unity can not complete because it hangs on a process rebuilding the libraries I removed, so I can't continue.

I CAN NOT kill it - I have to do a hard reset.

 

Unity?
Can I get a response? Please!?

 

I heard that there were some iteration fixes on 2021.3.14f1 so I promptly installed. Seems good to me, although don't have a project big enough to test the changes.

sschoener on Twitter: "Unity 2021.3.14f1 is out and there are a bunch of changes I put into this release (and all other releases!). Let's take a look Highlights are improved editor perf, improved animation perf, improved profiler perf!" / Twitter

 

Oooo, what kind of time gains are you experiencing?

 

(o*｡_｡)o
I'm sorry for misunderstanding...

 

Hard to tell, does seem a bit less 'hangy' if that's the word! I only have small projects so hard to test the improvements that affect larger projects.

 

Actually, there is 1 major change. As I use Burst a lot, I get the compile times in editor. These are down by a factor of 10-20x, which is interesting considering this is just linked to Burst.

 

These were previously all in at least 3 digits, up to almost 3 seconds.

 

Thanks for the update and transparency!
Fingers crossed that the higher-ups who manage and define the resource allocation realise the importance of working on core faster iteration times instead of any number of other random un-needed side features. Historically, Unity has often been chosen because of its faster iteration times. If that regresses then Unity loses a huge benefit and it becomes more attractive for the community for other engines with faster speeds (Godot and even UE5 are much faster right now).

 

Bro... At this point I would stop hoping that anything will improve anytime soon.

It really is just an issue of Unity developing the technologies needed for CoreCLR to work.
We will have to wait for that. In the mean time just use Godot for 2D, Unreal for 3D and Unity for Mobile 3D.

Hopefully the wait will be max 2 years, but this is being optimistic...

 

CoreCLR may be solution instead of Mono but please could you redesign, optimize and most importantly reduce C# codebase in half or more?
Also high amount of data flow in HDRP API, Burst, packages and libraries inevitably slow down the editor responsiveness and worsen script compilation.

I think reducing the API and codebase should also be part of the design plan.

 

Definitely! Unity's whole API is kinda bloated, if for backwards-compatibility or simply them overcomplicating stuff, it is bloated!

 

And.. what code exactly should do that what is missing then?
Sure there are some downsides of this as well, but all in all it was a good decision to take more stuff out of the black box which is the Cpp side of the engine. Thanks to packages being C# you can edit them! It's not extremely often that you need it but it enhances the engine to have that possibility.

Whether the C# code could be improved? Possibly. No codebase is perfect. Thinknit's illusory to believe the code base could be halved while keeping the same functionality. People would scream if they drop significant backwards compatibility as that locks out people who have to update their project due to appstore or console requirements.

 

Myself and millions of other people (and billions of consumers of games) currently rely on Unity being the best tool for the job because it is what we have invested our time into learning and building tooling around for our careers and income. Of course we are going to hope that things get better and improve.

But ultimately there is a tipping point in terms of productivity; as the workflows and engine becomes more cumbersome, problematic and slower this adds extra unwanted debt. Studios (and any business) are run on how much things cost compared to the return it gives for the task; iteration time is one of these factors. Ive already shifted one game im working on from Unity to Godot purely because testing on device & building to mobile is light years ahead; its faster for me to rebuild my entire Godot game and deploy directly to device than it takes to enter playmode in the Unity editor. That time saving scales up significantly and if Unity doesn't address this sooner then it loses one of the biggest benefits it has sold itself on for the past 15 years (And why many studios shifted from other engines and tech to Unity in the first place; the shift can happen again from Unity to other tool and could argue thats already happening as projects are being sunset and new ones started).

 

Still think they should start again and make a Unity 6. The other engines seem to make new/breaking versions. Saying that, I didn't use the older versions, was say Unity 5 a breaking change from Unity 4, or is everything built even further back for seamless compatibility?

 

I'm using 2021.3.14f1 now, but at the same time I bought a new SSD for my unity projects as I thought mine may be faulty.
I'm getting pre-2019 version iteration times, I have other SSD's - has everyone aligned their partitions? I don't know if it's related - I only had to 'realign' one, and that's the one my unity executible was on. It's been fine ever since.

 

THE JOURNEY BEGINS!
_________________________________________

Here's the source if anyone wants to follow with me
How to Check and Run SSD Alignment in Windows 10? (diskpart.com)

_________________________________________

So I first checked if it was already aligned... (see section SSD partition alignment check in two methods)

1. I opened msinfo32
2. I went to the disk and this is the result ( some of the specs are also there, but keep in mind this is a laptop so I'm limited to about 3000mb/s )
3. So the value was 999,547,731,968 bytes!
4. 
5. Now the only thing left is to divide this with 4096 aannnnnd????
6. I get a round number ( 244,030,208 to be precise )

So my partition is aligned...

_________________________________________

The Test

So the weird thing is Unity this time is somehow fast?

The first time I changed a line of code it took about 9s.
After that first "warm-up" modifying code was almost 3s-5s.

I turned down the Idle Import Worker Shutdown Delay setting ( In Project Settings/Editor ) to 1s to make sure the cores were fully idle, but it was still fast...

The Task Manager shows this...

DISCLAIMER: I DID QUIT EVERY BACKGROUND APPLICATION (e.g. Discord)



Also Unity itself is literally at 0% of the processes...

Conclusion?
So I guess they did something at Unity? Hooray!

I wouldn't call it pre-2019 iteration times, but it's damn usable, while we wait for CoreCLR!

_________________________________________

This was my OWN experiment feel free to report your own experiences too!

 

Hmm doubt if much has changed because my disks are all aligned, always have been, always been using SSDs too.

Unity 2021.3.14f1 takes about 3 s for a very large project (MRTK/Hololens 2 based) when I change a line of code.
But even a new empty project with 1 script takes about 1.5 to 2 seconds to reload domain etc when I change a line of code. (Almost same time as giant project with
atleast 100 classes)

I think this is still really annoying, wish it would take < 0.1 s

My times are always sub 3 seconds since always because this is with a very high end system with 7000mb read ssd, 7950x Overclocked, 64 gb ddr5 6000 cl30 RAM, 4090 all custom loop liquid cooled including the motherboard and ssds.(mobo/ssd also have a water block, so I guess it helps)

Before the 7950x, I had a 3700x and over there too, it was < 3seconds for basic projects, big projects took around 7 to 10 seconds)

 

No way you're complaining about 3 seconds XD

Welp anyways as I said...
We have to wait for Mono to be dead

 

hahaha, xD I guess 3 seconds ain't THAT bad

 

I've honestly not noticed wait times since, I couldn't tell you the last time I thought 'why is this taking so long'.
The only thing I did was change for a new hard drive where my project is based, and relalign my partitions on the drive my unity is installed (C

 

I had a 1.1s to ~2s speed up in iteration time in 2022.2.0f1.
Decent news I'd say but Idk if I'd be risking to upgrade my project over that for now.

 

2022.2 looks good:

• Scripting: Improved the startup performance of script compilation.
  
  
• Scripting: Performance improvements on startup time and code iterations.

i hope this gets tackeled very soon too: https://issuetracker.unity3d.com/is...-script-in-editor-became-really-slow-in-trunk i was hyped when it switched to active but i think that was 3-4 month ago?

 

What's maddening for me is that in one of my experiments my whole codebase + plugins folder only accounted for about 3.3 secs of the total 10s+ reload time and it's basically irreducible.