Official Improving iteration time on C# script changes

Finally this bug got moved to „wont fix“

https://issuetracker.unity3d.com/is...-script-in-editor-became-really-slow-in-trunk

its over boys. Close the thread

 

I can confirm the same behavior in 2022.2.12. While it isn't a permanent fix, clearing \library does decrease editor iteration time if the cache is old. Unfortunately, this is one possible solution among the many required to improve iteration time. Ultimately, Unity has to remain focused on improving iteration time.

 

I believe this is the issue you are looking for: Unity Issue Tracker - Increased Script Assembly reload time (unity3d.com) It is a catch-all for editor iteration performance work. If you review prior posts in this thread, you'll learn more about Unity's plans for addressing the issue.

 

Have you read the resolution note there?

"
RESOLUTION NOTE:

I have filed several issues separately to fix particular parts of this that were slow. We have a Prism dashboard now to help monitor iteration times on a broader scale. The team are working on CoreCLR where we hope to make a big improvement to this issue, but we're unlikely to work on fixing this specific bug report."

 

Everyone has, and we're all familiar with this pattern, too:

1. Problem too hard, promise a big new shiny thing in much time...

2. ...delivery half arsed thing with more problems and promise to fix until it too problematic - goto 1

 

In this case I would rather say the bug report is too generic.
Unity has "improved" performance in many areas, however, these performance improvements have been offset by new features. Without these improvements, it would be even worse now.
I think Unity with Mono has reached the limit of what is possible. In my opinion, CoreCLR will have a massive performance boost (once the editor runs on coreCLR and .NET 8)

 

Not to sound rude, but it's hard to take your opinion of it seriously when you don't even know how to spell it. But it appears we're still years away from CoreCLR. Even just a few months ago they said they're far away. At the rate Unity moves I'd think 2025.1 would be very optimistic.

 

I am the master of twisted letters!

I think CoreCLR will come with unity 2024.x for player build, editor as you say 2025.x. Unless the plans have changed and it's coming at the same time.
As far as I remember, at first only CoreCLR will come, but the profile stays with .Net Standard 2.1, and only later .NET 8 when both player and editor are running on CoreCLR.

I think it is now difficult to justify wasting enormous resources on optimizing things that are of little use in the end and are again obsolete with CoreCLR

 

I came for a solution, all i found is just depressing

 

Well, I am somewhat relieved. I thought i had been wasting 5 seconds an iteration for years without knowing it could have been faster.

But it isn't and hasn't. (Has it? Im on 2022.1.16f)

Whew.

I guess it will be what it will be until it isn't.

In the meantime, I think it's time I rebuild my library folder. Its been six months or so...


EDIT:. After deleting rebuilding my library folder, it went from 10Gb to 6, and script compilation went from about 7 seconds to about 4.

 

https://unity.com/releases/editor/alpha/2023.2.0a22

 

Can someone please try this and let me know if the compilation time is reduced when using fewer and more files?

 

I don't know how many individuals experiencing this issue fall in the same group as me but what I found causing the vast majority of my slow compilation and reload times was a poorly designed custom editor script (10-15 seconds to over 2 minutes during a 24-hr period). I had the script attached to multiple prefab objects as I was refactoring and testing functionality. After looking through Editor.log and seeing issues in the asset importer window pointing to this editor script it gave me an idea on where to focus my efforts. After refactoring the custom editor code and removing redundant testing prefabs holding references to the underlying editor class my reload times have dropped below 10 seconds.

I just wanted to let people know the issue is sometimes self-created or possibly from poorly designed 3rd party assets imported into your project. Reading through this topic might make some people believe it is 100% Unity's issue and there is nothing they can do about it. I thought that, but thankfully I took the effort to figure out it was my fault.

 

This affects completely new, empty projects without any 3rd party assets, which is why people correctly believe it's 100% unity's issue. The slow reload script assemblies issue is affecting many, but not all people, so the community is split into those who are unaffected and those who find development intolerable due to it.

So many people are reporting this issue in forums all over, many of them veteran developers who have years of experience with unity: this is a genuine problem with the engine today and not due to user incompetence. In the past few years I have personally experienced it and seen my peers struggle with it, so it is disappointing that Unity continues to be unable or unwilling to address this.

I have been a longtime proponent of Unity in the past, but I have since switched to other engines, as have many other developers I know. Unity is simply no longer usable and there has not been any action on this for years.

 

They said 'sometimes' and not 'always'.

Sometimes slow domain reloads are the result of some issue on the side of the user. It might be poorly written editor code, it might be their hardware is not up to snuff, it might be their project is running off a HDD (yes this has happened).

But not always.

Hence why it's important to profile the editor and see where the most time is spent during a domain reload. As someone who makes a lot of my own editor tools I do profile them to make sure I'm now bogging down my other projects that depend on them, and there have been multiple times where I needed to fix a performance issue.

 

I am a day late, but I just came here to wish happy birthday to my comment,
one year down, only two more to go, see you in 2025!

 

Hi,
Is anyone aware of any good tutorials on what users can do to improve domain reload times?
I came across this article by John Austin, which is great, but I am looking for more / more detail.

(For context, I currently have near instant script compiling but 15 to 40 second domain reloads. I've been looking at the Editor Iteration Profiler but I'm finding it a bit overwhelming. I've got Reload Domain on enter play mode turned off. I've looked at Hot Reload, which looks cool, but its not really the solution I'm looking for. And for what its worth, I'm making use of assembly definitions and running Unity on relatively competent hardware: intel i7-13700K, M.2 NVMe drives, 64gb ram.)

 

Sebastian Schöner, who worked for Unity until just recently, posted this big blog post about this theme, it might be worth reading!

 

The article was very helpful. Thank you!

 

i need to admit, i didnt really cared about this problem anymore. i was stuck on an old project anyway that was using unity 2019 and there the compile times has been fine all the time. I started a new project today and evaluated a few versions and i must say. i am impressed with the latest LTS version of unity 2022!

unity 2019LTS: Script compilation time:1.772s
unity 2020LTS: Script compilation time:1.867s
unity 2021: Script compilation time:3.235s
unity 2022 LTS: 1.765sec

these are the compile times for an empty project without any package.
so. good job unity!

 

Have you tried script compilation HDRP ?

 

2.5-2.8 seconds

but i also (need to) have 11 packages now

 

Just a note for anybody who might need to hear this - I kinda solved this by buying a new laptop. From 20s assembly reloads to 4s. Much better.

 

I'll admit the same. I traded a fast laptop for an even faster desktop. An NVME Gen4 SSD w/ high IOPS and AMD 7950x processor gets me down to 3-5 second iteration time. I still have to clear \library once a month because iteration creeps up slowly over time.

 

Assembly reloads get faster after you clear the \library folder?

 

For those that don't want to spring for a new machine, maybe give this asset a try?

https://assetstore.unity.com/packages/tools/utilities/hot-reload-edit-code-without-compiling-254358

I've been using it for the past few months and it's kind of a life saver. It's definitely a little unstable, and needs to do a full Domain Reload in some cases, but the time save it provides when you need to change a quick line of code is unmatched. Being able to make code changes in Play Mode is just a cherry on top.

 

Hey Peter. I'm 100% positive editor iteration performance improves. This is the time from script change to the editor being usable again. It requires an old library folder -- in my scenario this means about 30 to 60 days old. One theory I have relates to asset database indexing, or the number of precompiled shader fragments that exist, combined with file/io performance.

An old library folder for me is typically around 100GB and it has several million files. These files may include cached build output for different platform targets and platform-dependent precompiled shader fragments.

 

I have to do the same every 2-3 weeks (even on i9-14900K + SSD PCI 4.0). A friend found that hosting the cache on remote server helps, but I don't have a NAS server so maybe someone else can give it a try.

 

I've used it for a bit and turned my life into hell. I guess it depends a lot on your workflow? It doesn't support a lot of different things that can break the game and create a lot of headaches. For example, adding a new method to a script won't show up in the list of functions to call in the animation event. Or it doesn't update the shaders that get edited in the text editor, so it forces you to refresh assets every time.

I would say try it but don't expect miracles.

 

my machine is no slouch, sure its a few years old, but its no slouch it was the best it could be in its day. I think the thing that bugs me most is you make a new empty project, you wait a small eternity for unity to load.. its forgivable for the most part dont get me wrong, but, you then right click make new script.. its empty, we all know its basically empty... "importing assets.." ... "recompiling domain" .... Now sure, i also know it just saw a new file, its doing what it has to to check what to do with it, but, on an empty project i expect this to be quick, not taking enough seconds that these two boxes are the boxes i seem to spend half my life looking at.

 

@xoofx Are there any updates you can share with the community? There was an initial push to quantify iteration performance and create baseline metrics to compare against. Does your own data tell you things are getting better, or are we treading water?

 

I'm also interested in this, especially for HDRP improvement.

 

Man this makes me sad, a thread from 2021 and Unity is still completely impossible to work with, 10 second wait time for a single script project with one prefab and nothing has been done on top of absurd load time. I used to run unity on my crappy laptop with no load times at all.

What happened.

 

A greatly expanded codebase with much more features and systems that need to be taken into account when compiling. It's inevitable compile times would increase some. But also, they drastically *reduced* compile times for very large projects. Once you've got a large project going the compile times still remain fairly low. So there's initial constant overhead to save time on larger compiles.

For me personally, if the project is on an SSD and 12700k, a single script project is going to recompile in a few seconds, not 10.

 

10s is a long time. So. While i have no usage of plasticscm for example.
I know my machine ran better for

excluding the dev folder from my av
Making sure it was on my fastest disk
Not having some source control also checking if id changed any files
Using the asmdef system to break code into chunks so rather than all it compiled few

is it perfect. Heck no.

like my post earlier i see the importing asset and domain boxes so often it can feel like thats all i remember of a coding session. But then. Im also awaiting (not overly patiently) on a new computer which should be plenty faster than my current. Why? Because in tired of waiting and tired of running games on lower settings than i should have to considering what i know from my work with unity.
(No offence arpgs but if all i get to see is like a 7m sq plot of zone with a bunch of mobs and some fancy particles. My 2 1080tis in sli, oh wait most games these days dont support dual cards, should be ok at 1920x1080 not needing to be on low. )

so a nice shiney 14800kf with 64gb memory a 4090 and a whizzy disk hopefully will appease some of the "waiting" gods. But tbh. I doubt it. It just wont be as bad. Too much is single thread. But hey. Hopefully it can be another 7 years before i buy a new one.

 

Your PC sucks. That's what happened.

I have a project with hundreds of prefabs and several hundred scripts (in the main asmdf) and the iteration time is well below 10s.
On an R 3900X.

 

while Unity dont have buitin solution use this asset https://assetstore.unity.com/packages/tools/utilities/hot-reload-edit-code-without-compiling-254358
With it iteration time goes to Zero even w/o living play mode

 

My only frustration with this asset is once you used it on one, you all but have to use it on everything as it changes generic IDE settings, so that you make a test project to do something in and now its not spotting changes or anything by itself, you now have to manually force it etc.

 

Could you elaborate? Considering that asset, thanks.

 

My experience - and for some reason i seem to bring out the worst in everything, but, i loaded it in one project to test it, cos i bought it, i poked about a bit. I then closed that opened up a project with actual work in, and now the project behaved oddly, script changes werent seen but i remember it felt more than that.

As a result, once unity was gotten back to working normally, i havent loaded it again

PS although now is the time to get it. Its on sale!
PPS i havent tried the latest version and maybe they fixed some of the things that bugged me

 

Not fixed this is expected behavior everything in settings tab of asset and default settings looks like that

 

it wasnt their settings.. it was the normal unity settings.....

 

What's the point of even denying that this is a problem?

A i7 6700k should have no problem running a simple script parser and it's also almost equivalent of yours. Reloading one script taking 10 seconds clearly isn't a fault of the processor.

 

The problem with this issue is that it does not manifest consistently for all users. It is a function of project size, installed packages, library contents, and installed platform build assets. For some users it may involve self-inflicted harm caused by asset database queries during scene reload.

It has not been fixed. I can't be any more clear -- for projects which follow best practices and operate at scale (5000+ scripts/prefabs) the issue is unresolved.

The only way Unity is going to reliably address the problem is to collect telemetry and quantify iteration performance for a variety of projects and configurations. Using starter projects to measure baseline performance is not going to identify the issue (https://forum.unity.com/threads/imp...-c-script-changes.1184446/page-3#post-7824810).

Unity committed to sharing metrics for editor iteration. But given their reluctance to follow through with new releases, it is likely this issue is delayed until they release the Core CLR runtime.

 

From https://forum.unity.com/threads/unity-future-net-development-status.1092205/page-48#post-9603908

 

Interestingly enough, using the Parrelsync Clones manager :
The Clones are way faster than the original. Reload times, compilation time, as well as when running !
My reload time for a little baby testproject just to learn netcode is about 40-50 seconds !

 

I posted a message earlier in the thread about aligning partitions on my SSD hard drive - I know my problem with iteration times were possibly related to hard drive, and after buying a new one and aligning the partitions on my main SSD (C Drive), I've not had any problems since in two years. I have a 10 year old PC, so it's nothing to do with 'PC being bad'.

 

Single threaded performance of a current generation (7950X) processor is double that of a ten year old (4790K) and multithreaded performance is almost 8x. For script compilation that means what should be taking 3 to 6 seconds will take 6 to 12 seconds and for lightmapping what should take an hour is taking eight hours.

I don't even think motherboards of that time period had M.2 NVMe drives so unless you've added one of those PCIe-to-NVMe add-on cards you're also running an SSD that is at most 550MB/sec when most drives today are 7GB/sec with the fastest being up to 14GB/sec. So a 12 to 25x performance difference.

You can make it work if you just can't afford anything else but having made the leap to a decent PC (5950X, 64GB RAM, PCIe 3 SSDs) a few years back I can tell you the computer you think isn't "bad" is much worse than you think it is.

You're not running a simple script parser. You're running a complex compile chain. It's been a number of years but there was a benchmark by Gamer's Nexus where they ran GCC compile benchmarks on a processor with an at the time unusually large cache and they found that it was many times faster for it.

A 7950X3D has 145MB cache (1MB L1, 16MB L2, 128MB L3) while your i7-6700K has a mere 8MB. That's 18x more cache which means that a modern processor can fit 18x more code into the cache before it has to start relying on memory. Speaking of memory your computer is on dirt slow memory by modern standards.

A 7950X3D is rated for DDR5-5200 which comes out to about 86GB/sec. If you're on decent memory you might be hitting 34GB/sec with your 6700K but if you're just on standard speed memory it's only 17GB/sec. So a 2.5 to 5x difference and it's not even the fastest DDR5. Fastest is currently DDR5-8400 which is 134GB/sec.

You mean aside from the ones seeing the worst impact from this just happen to be on the worst systems too? To be clear Unity isn't blameless here but an old computer multiplies the effect here with a computer that is 1/3rd as powerful now taking about three times as long to do the job (ie 10 seconds instead of 3).

 

I have thought to test one day, installing Unity/central onto a ram disk and seeing how much this speeds up everything. Do feel like random accessing of 1000s of locations on disk are a proportion of the slowdown but I might be wrong. Copying 1000s of small files is slow even on fast drives, due to access latency which stacks rather than bandwidth.