Official Improving iteration time on C# script changes

That's what's confusing me, I had tested a new empty proj with 1 plugin and 1 empty mono script to track iteration time a couple of months ago on 2022.1f, every code change took between 4.5s and 5.3s from what I recall so basically even an empty proj has an overhead of roughly 4 secs if we don't count the plugin (note that I removed the unnecessary initial packages like VStudio, Visual Scripting etc.

Let's say my total codebase in my project (including 3rd party plugins) accounts for +/- 4 secs currently (as opposed to the time I made the experiment as stuff keeps being added), another 4 secs go in the overhead mentioned previously then the remaining 2 secs or so would likely go into additional Unity packages and maybe refreshing prefabs (even on a minimalistic version of the project with only essentials to run) as part of the AssetDataBase.Refresh() step involved in the iteration process.

 

I'm on 2022.2 and its not faster at all its arguably slower or unchanged.

 

To achieve sub-second editor iteration time you just need to throw better hardware at the problem. Minimum Unity system requirements listed below --

 

This is quite a waste of money since you only use 1 core for script compiling. So a 13900k would be your best investment.


Oh.. that was sarcasm… yes, lol

 

Just to update - I'm still on 2021.3.14f1 - I upgraded from 2019 I think about four months ago and compile wait times have never gone above a few seconds, I reckon on average about 1.5 seconds. I've not noticed it really.

I don't know whether aligning my partitions, moving my project over to a brand new SSD, or in fact upgrading to 2021 did anything, but one of those certainly did.

BTW I'm still using a ten year old i5-4670K with 8GB of ram and a 9 year old Geforce GTX 980.

 

True Dev Setup XD

Still though! Even with better hardware I have THE SAME TIME as you! HOW????
Like here's my setup:


So maybe the problem is smth with RAM?
Because I actually have something super slow...

CAN SOMEONE PLEASE TEST THIS? With A DDR5 Kit or smth?

 

Lowest I've seen it was 3.149 seconds in Unity 2021.3.16

Slightly downvolted i9-12900k, 32Gb DDR4 RAM @ 3600Mhz, Samsung 980 Pro NVMe.

Project approaching medium size I guess.

 

Hmmm sure so even faster/better RAM didn't change anything
I honestly don't know where the bottleneck lies, and I don't expect it to just be in the CPU, as the Unity Team has already tried multiple times to optimize that...

The problem may be with the latency between the managed and unmanaged side which can't be really resolved unless
some stuff is brought to the other side which also is just bad...

Any Opinions?

 

Not a hardware problem but faster does equal better.

You know this because Unity 2019 recompiles/reloads quickly and all subsequent versions of Unity do not. The exact cause is described in detail at the top of this thread. The move from monolithic architecture to packages, with each package bringing its own initialization (app domain reload) slows iteration down in aggregate. There weren't metrics in place measuring this slow down and it slipped past their radar.

 

If Unity was installed on a RAM disk, would it make much of a difference? I hoped to try it one day. Thought maybe some slowdown is due to file access. Regardless of SSD/NVME speed, I find copying small files is still way slow. So if 5000 files are accessed, how much time is spent just on that?

 

This is a terrific idea. I would try this out but my library folder is 115GB. I don't have enough RAM.

 

It does not seem to be the files. At least not always. I only have a relatively small project for this (1Gb without lib folder, 2.7Gb with lib folder, 676 .cs files in the assets directory) and there is exactly zero difference.
Project starting time is 15s in both cases and code reload time is roughly between 6.7 and 7.2s in either case. Have compared a quality NVME SSD (with cache and via PCie3.0) against a 6GB ram disk.
CPU: R9 3900X
RAM: 32GB 3800Mhz DDR4
GPU: RTX 3080

EDIT: There is a lower limit of course. I put it on an USB 3.0 stick and launch time raised to 24s and code reload 8.5-9s.

 

Not sure if ProcMon reveals any issues, I find it to be a powerful tool. Isolated 'mostly' Unity stuff going on, (accessing project library constantly, excluding Unity HUB which last I checked, accesses every project in your project folder constantly). Did some analysis of 30 seconds idle and 30 seconds idle including creating 1 C# file in Assets and awaiting Domain Reload (minimal project).

But don't know much on the results below, whether it's just normal. Whether these are minor things in the whole picture and I'm just clutching at straws.



Idle including create 1 file and await domain reload

 

2500 ms dictionary lookup... ouch (12900k with 3600 cl16)

 

Despite being both perfectly predictable and instantly observable. They had to know, but were likely too busy grooming themselves for the IPO.

Remove all packages. Now add back only the bare minimum. Not SRP nor Burst/Jobs etc. Use Builtin. Avoid the new input system, new UI, everything since 2018.

Iteration time is massively improved. But you're now using Unity like it's 2017.

Which isn't all bad.

 

I rarely use the forums to comment, because I feel I have much more to learn, than to teach. However this is getting ridiculous.

I upgraded my XR project from 2021.3.6f to 2021.3.16f. The project size went from 3GB to 4GB. Ram usage from 2gb to 3gb making my system unusable when testing multiplayer (2 editors + IDE). I would use a less bloated IDE, but you guys stopped supporting visual studio code.

So now, I can barely develop my game, all because of upgrading to a minor patch.

 

As unfortunate as it is, fear a machine that struggles with something hogging just 6GB ram is just not a machine meant to develop on with an engine that is capable of AA-titles...

Heck, my Chrome hogs almost twice as much X3

VSC is inferior when it comes to C#.

 

Is not 6gb of RAM, i've rounded numbers. VS is taking 4GB and every unity instance up to 3GB with memory leaks every time i press play. I wouldn't be complaining if this increase in memory usage was something that would be expected in the face of new features in the editor. This is not the case. And every version is worse.

I'm not talking about a full 100gb project. I'm talking about a prototype with one simple scene, untextured models made in probuilder and code. (no shaders, no terrain, no anything) The point is that a minor patch should not change development conditions so abruptly. Especially when the patches are pure bugfixing mostly needed in any game.

 

You can safely downgrade back though yes ?
Tbh I also stopped upgrading to minor versions cuz most of the time I get new issues without the old ones fixed so I tend to just lock on the one that seems the most relatively stable/less inconveniencing to me.

 

Iteration times were a significant (probably the most significant) bottleneck for us. Bugs or other optimizations to improve iteration times aside, it likely still wouldn't have been enough in our case. Our game is more than 2 million custom lines of code, so it's likely none of the proposed solutions and improvements in this thread would have brought iteration times down significant enough - especially when you include the time it takes to get back to prior game states to test changes.

In the end, we built a C# Hot Reload extension for Unity which we just recently made public. It works pretty much as you’d expect Unity’s default “hot reload” functionality to work, but with lightning fast compiling and no domain reload (so your variables stay intact). Basically we made a C# compiler which only compiles the specific method that changed (which is very fast, milliseconds), and then we swap just that function in playmode. Now we have < 1 second iteration times in our project rather than 2-3 minutes.

Feel free to check it out on our website hotreload.net or on our Unity Forum post if you're interested.

 

I'm evaluating it now. I do think it needs to support having a connected debugger and allow debugging for unmodified files. Otherwise, I am gaining productivity in one area and losing it in another. If you can get all of this to work, I'll gladly give you my money.

 

First of all this should be in the other forum that he created (where you already commented).
Anyways I would assume this works, as this is just a compilation framework, meaning anything that runs will be catched in memory by the debugger and will show up (unless I am understanding smth incorrectly about debuggers)

debugging - How does a debugger work? - Stack Overflow

Also in theory a debugger is a hot reloaded machine so in of itself it should be able to support such capabilities. (change variable values, change step position, etc)

 

Aaaaaaaaaaaaaaaah I'm so tired of using this ********** slow Unity!!

Just a little rant after long day of Reloading Script Assemblies, sorry...
Unity, do something!

 

Please, could you take this task for improving iteration time on C# script changes as priority during Unity 2023.2.
This fix is critically needed for for Burst compiler and HDRP?

 

It seems to be able to run Substance Painter, Houdini, Unreal Engine without any problems whatsoever - was something in my PC a superpowered prototype that escaped somehow, I don't get what's going on with the amazing performance of my 10 year old PC.

My compile times etc are still completely un-notiably normal still, it seems to be going OK with 2021.3.14.

In work I'm compiling C++ in Unreal using 'Live Coding' and that takes around 1 - 3 minutes for even the simplest blueprint function library class and you have to do it manually.

 

I came across a tool yesterday on Reddit, which lets you skip all compile times in Unity.
They said "It’s free forever for all Unity Personal users, and Unity Plus/Pro/Enterprise users can get a 7-day free trial followed by free 2 hours a day of usage until purchase (after which case it’s unlimited usage, no restrictions)."

Here is the website:

https://hotreload.net/

Here is the discussion link:

https://www.reddit.com/r/Unity3D/comments/10v66xi/we_just_released_a_free_tool_which_lets_you_skip/

 

That is completely wrong...
This tool allows you to hot reload scripts and doesn't remove script compilation!

Also it's not on reddit, but here XD

Anyways... they have a forum on Unity which is way better...
HOT RELOAD - Edit Code Without Compiling! - Unity Forum

so yea...

 

Spoiler: We're fairly off-topic

That may not be true at all lol. You have to keep your tools updated to a stable version. By tools I mean photoshop, drivers, engine, packages (like TMP), Operational System, BIOS, etc...
This can fix various stability issues, bugs and security breaches.

It's recommended that you update for example from 2020.1 to 2020.2. Updating from 2020.1 to 2021.1 would be a different story and it would have to be calculated. (same for ECS updates)

I'm not having locks on 2021.3.16f1

 

Spoiler: We are still fairly off-topic :P

I would assume, that that's what they meant

 

You can still get VSC compatibility back by adding this package by name: com.unity.ide.vscode
Sometimes I really do wonder what goes on in the Unity devs' minds. Out of curiosity, I decided to download Unity 5.6 and mess around in it, and unfortunately have found myself being even more productive compared to the newer Unity releases.

 

I don't agree. I give no regards no matter if its a Unity dev nor executive. Because a lot of peoples make their(biggest?) mistake in a life to chose Unity as an workspace. Unity was advertised to be simple, popular, functional, effective tool. They promised a lot and did nothing. Ignoring most of our threads and hiding from us on their own forum, to not speak with us. If you think that unity devs are not so bad and they are just dependence on executives, then why they chose to work on them at all? How much developer should be competent to work with proprietary game engine in 202X year? You need to understand me clear here, because engine is not just some kind of messaging app or something "trivial". Engine/Editor/Service used by DEVELOPERS. Its not a game, its not a product. ITS A TOOL FOR MAKING PRODUCTS. For making IT-Products(!). By developing such BS you are making world really more bad with such junk. Developers suffers, their products suffers, their business suffers and of course it can result in less-quality of end-product because a lot of time was spent on waiting and fighting with Unity issues instead of developing actual product.

 

@unity_QJ7RazXzghZCzA
Lol.

 

You need to read all this thread and notice how bad unity is. There is tons of such threads and unity completely ignoring our needs and problems. You have just begun to dig in this sh*t and you will encounter a lot more of limitations, bugs, etc. Change to Unreal or Godot while its not too late for you! Never recommend Unity to anyone. Good luck.

 

Chill, user with a GUID in their name XD

I don't totally disagree with you, especially when Godot announced their latest 4.0 update, but I wouldn't go as far as to discourage Unity from every Noobie!

Unity still has many more Tutorials, UX Simplicity, and better compatibility with C# than Godot!
Don't even try to mention UE 5 to a beginner, Blueprints is cool, but it doesn't help teaching basic syntax found in every programming language and C++ is... y'know...

 

And then you discover that serious Godot bugs have been known for years sitting in GitHub issues but go unsolved because no one wants to work on them, which is the nature of open source. At least with commercial engines someone gets paid to work on the boring stuff. Or you discover that Unreal takes forever to recompile, hot reload is unstable and builds take much more time than Unity, etc. No engine is perfect.

I was all about switching not that long ago too but then reality kicked in. The worst engine is the one you're currently using without exception.

 

Very well said. That's also true for web frameworks, data visualisation tools and even IDEs

 

The weird looking usernames are a result of Asian language entries into the forum name slot at signup.

The points this person (unity_QJ7RazXzghZCzA) makes are valid. And consistent with the experiences of many users.

 

Then take his example to heart and switch. Why are you still here?

 

Probably to help your eye to see.

 

When you're a professional developer, you do as you're told. You're paid to do what you're paid to do, not what you think is right.
Unity is not open source like Godot, devs can't just do what they want. There are many reasons for me to choose Unity over the others, every engine will have flaws, the devs are not to be blamed for corporate decisions, only for bugs (and you still would have to account for time/money defined to be invested on those features).

 

As the saying goes, "There's only 2 types of software. Software nobody uses, and software people complain about."

 

I was wondering why iteration speed is so slow with only 1 script in a new project but then I recalled I hadn't removed Visual Scripting yet. It's the single biggest speed gain you can get right now.

 

The main problem here is not just limitations, bugs, unstable, incomplete features etc. but in a couple with the fact it will never change. You get it, when see forum thread almost two decades old, where peoples that was children when joined in thread already has its own children's, they are writing about it with laughter on their face and Unity still did not responded on their thread, nor fixed trivial issue. Wanna see it? Enjoy: https://forum.unity.com/threads/ragdoll-wizard-quickie.3649/#post-8736921

Just imagining how much of trivial trash hides in their proprietary code, that could be fixed in one day or something. Its not a problem when everyone can fix it and forget, in case of openness...

 

A while ago I posted that removing the Visual Studio packages (I use Rider) made a big difference. Working on a project for the Asset store I realized that I could remove TextMeshPro and Memory Profiler which also allowed me to remove Editor Coroutines. Although I suppose most people need TextMeshPro, this again helped quite a bit.

But this doesn't address the problem really.

Watching this thread for quite some time now, it affected my own dev work. What I'm working on has a number of static class libraries that have allocs for many lists, dictionaries and so on. It occurred to me that I really ought to change the way initialization works.

Basically, I removed all non-essential initializations from Constructors and methods that get invoked because you've tagged them with some sort of initialize on load attr. Non-trivial due to the ease of inadvertently causing nullref exceptions. Turning on Rider's nullable support helped quite a bit with that in many cases.

I removed as many constructor-time field allocations, so no public Dictionary<A,B> = new(128).

To make a long story short, I changed things around so that as little as possible is done in constructors, rather, inits that take time or alloc memory for collection instances happen at first use rather then during reload. Is this all too obvious an optimization that everyone does already?

This actually had an affect on reload time. It's hard to say how much but a SWAG would be about 20 pct.

Again, I don't know if this is obvious or has already been done internally at Unity but I wanted to pass along this info.

 

But wouldn't this affect start-up time, which therefore also affects the person who is playing our games?
I would rather suffer in the editor than passing my "debt" to the user...

 

The initializations and memory allocations have to happen sometime. In a built app they'd occur when the program loads when the init is built-in to the variable declaration.

So you're not shifting it to the user, really. I think that'd only be an problem if the static class wasn't used often and you ended up initializing it at a point that might introduce frame drops because the initialization time took too long. In that case its a system design issue.

I'd assume that the system designer would just init those sort of classes right when the app is given control from Unity's startup code.

But your point is well taken. However that doesn't matter for editor extensions which is my (personal) focus.

{EDIT} The main point I was getting at is: if there are static classes in what will eventually be runtime code but are present anyway during editor sessions, this will impact the domain reload (etc) times for really no good reason. It's a common practice to use declarations with initializers.

 

2022.2.13f1 (latest as of today).
Iteration times have increased to 45 - 55 seconds avg per line of change in a script file.
Earlier it used to be 25 or so seconds a month ago so I didnt care much ... not sure what I did wrong. Very frustrating...

Computers are getting slower ... sigh...
My Rig: AMD Thread Ripper 32 core, 64 logical processors, 64Gb DDR4 3600 Ram, 2 Tb NVME drive.

 

Can anyone check this code and tell me if this may affect Domain Reload performance?

 

Two years later and the compile times have gone from the OP's 4-6 seconds to ten times that. My iteration time (and overall productivity) is absolute trash now (even with endless hacks like turning off domain reloading and using assembly definitions and getting rid of bloatware packages), and it isn't even using most of my system's resources while it works.

This is Unity's #1 problem right now, but no progress seems to be getting made on it (in fact, it seems to be actively getting worse!). It's very disappointing to see this once-useful game engine degrade into uselessness.

 

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