Unity Editor Slow as hell even on modern PC configuration

Unity Editor slow.
Re-draw itself on CPU every frame.
Long enter in and out of play mode.
Long re-compilation.
VERY LONG import of assets.
Very big overhead in size of project on disk with a lot of small files.
Extremely long time for the build(android for example) when you just changed only one field of scriptable object etc.
Long load time of editor.

Please everybody - add your voice, this should be changed a lot of years. I lost my entire life for just waiting.
My PC configuration:
Ryzen 5 pro 4650G
RTX 2060
SSD(Only for Unity projects) 970 evo plus 1TB m2
24GB DDR4 memory
Thanks.

 

How much is "long", "very long", "extremely long", "slow", "slow as hell", "very big", "entire life" and what are the units for each?

 

Hi. Exact time is dependce on project size and PC configuration. But with several gigabytes of assets it can take hours to just import project on low-end PC or hour-two on my configuration. Build of 100mb in size android game takes 5-10 minutes in additive build mode, when you changing just one field in prefab or scriptable object(mostly while testing vibration or when you iterate with optimization or with simple bug fix). Its feels too much for such simple actions. Why shaders should be recompiled and assets re-packed when it does not changes at all?
To recompile just my game code(Im actively using asmdef files to speedup this process) it can takes like 10 or more seconds. For a hypercasual or simple casual mobile game. What would be with mid-core projects?
Opening of the same project on my configuration can take like two minutes, but on low-end pc it takes 5-10 minutes.
Unity Editor it-self very limited on its speed and if you will open inspector with some component with custom drawers - it will fall your FPS in editor to like 5-10 with game view.

 

Most time of the Android build process my CPU load at level of 5%+- and load of my SSD is several megabytes. Why it cannot be optimized? Why things that was not changed in build should be re-builded from near zero?

 

What Unity version? Did you try different versions on the same project? Unity did improve asset import and other performance metrics of the editor over the past couple years.

Keep in mind that more often than not, performance issues like these aren't necessarily Unity's fault. For example, some virus scanners can be (configured to be) rather aggressive, causing a tremendous slowdown on any disk access of any file type. And so could missing/outdated/buggy drivers/firmware or conservative BIOS settings or software-encrypted/-compressed drives/folders or cheap motherboard limiting memory/disk throughput and so on.

There are plenty of other things that could slow down even a modern computer where it really only shows when using a heavy-lifting tool such as Unity editor with a non-trivial project, or very demanding games. You could for instance download and run Passmark to compare your computer's performance with that of similar computers, to check if you have a bottleneck in your system (CPU, SSD, Memory, GPU, ..).

If that doesn't reveal anything out of the ordinary, I would check the project itself. Maybe there's some editor script that keeps making changes, or unnecessarily calls AssetDatabase.Refresh. Or misconfiguration, such as always building a release configuration rather than debug (builds faster but slower at runtime).

In my experience 99% of performance issues are caused by one or both of the above, that is computer configuration or project inefficiencies. The custom drawer issue is most certainly an inefficient editor script, either simply drawing too much (Gizmo drawing is slow) or simply inefficient.

Here's my today's Passmark for reference:
https://www.passmark.com/baselines/V10/display.php?id=167002419886

My diskmark result is rather low probably because the EVO that was tested isn't the fastest anymore, whereas the project drive I would expect to be a lot faster.

 

I worked on different Unity versions. The last one is 2021.3.x
I really dont like your position trying to find problem in our hardware. This is sounds like you have no idea what is means to be fast working software. Unreal/Godot seems to be faster in all manners.

 

Those cannot be compared.
Godot is a way more minimalistic engine with an interpreted scripting language.
Unreal, if you do C++ programming with it, you'd probably welcome a constant 10s compile time.

I'm not trying to find a problem in your hardware, just trying to make you think about what could be causing issues, locate them, and hopefully fix them - rather than just blaming it on Unity. You haven't provided any insight into what you attempted to locate and fix possible performance degradation besides putting the blame solely on Unity. Which makes it seem like you're not even interested in improving the situation for you and your team.

I don't know your project, but I did work with many Unity projects to know that Unity editor performance degrades for a reason and many times you can do something about that yourself, be it the hardware, the BIOS, the drivers, firmware, background processes and last but not least, editor scripting and plugins and judicious use of settings, assets and their formats/settings, and asset pipeline both editor and external tools, for example badly configured or misused source control overwriting assets in the project causing unnecessary re-imports.

 

10s compile time anyway better than 25-40 seconds in Unity with Ryzen 5 Pro 4650 while using asmdefs...
Imagine now I should upgrade whole my computer to buy top CPU just to make Unity compile code for 10 seconds... How should work peoples with weaker hardware? Why we need top-tier hardware just to make it work with moderate speed?

As I explained Im working on mobile-project that originally started as hyper-casual and its transforming to some kind of midcore. Yes, I have a lot of assets, but all assets separated into asmdefs. There is no problems with version-control system and assets overwriting. I googled a lot and ended up with conclusion that unity-editor bottlenecked itself. There is no possibility to fix long recompile time. Else if you know, please let me know. I also mentioned problem with long build process even with increment enabled. I dont know what you asking here about, while I described everything clearly.

 

I dont know why you prefer to think about problems with my BIOS, drivers rather than Unity, while its widely known fact about Unity performance bottlenecks. This is not a question on how we can improve situation by using already known methods such as asmdefs, updating drivers or knock your PC with a leg to make it work faster. This is fun. We are talking here about performance problems even after all possible steps was made.

 

How many asmdefs? If you have a lot and small asmdefs and the dependencies all "bubble up" this can hurt compile times. Especially if you often modify assemblies that many other assemblies depend on. Applying Dependency Inversion Principle at the proper architectural transitions help.

This is what NDepend has to say about many small assemblies (equals asmdefs):

 

I had hung in 2020 version of unity until these day, after I upgrade from 2020 to 2022 version, I found unity became a CPU consuming monster- actually it becomes as slow as unreal engine on my i5 intel CPU.

I use some default template as trial, even a simple reload task after compiling takes almost 10 minutes to wait.

I tried to downgrade to 2020 version and everything is fine now.

 

Today in my mid-core project any change of any prefab takes about 10 seconds to reimport it and about 2-3 seconds just to open it. Script recompilation takes 40 seconds for any change(while using asmdefs everywhere) and entering in play mode takes 1 minute. I know I can avoid last problem by disabling domain reload, but unity itself has bugs with disabled domain reload. I think when I will buy PC with Ryzen 9 7950X speed will increase in 3-4 times so my 40 seconds will be shortened to 10 seconds etc. which is still way too long, but there is just no more powerful CPU on the planet right now for Desktop PC.

Also when reimporting entire project your PC will burn like hell:

 

"mid-core" is not a term that puts your project in relation to anything. You could provide the size of the project folder or the number of assets, that would be slightly more relatable.

How many is "everywhere"?

Asmdefs by themselves do not speed up compilation. In fact, too many asmdefs will actually decrease compilation time.

You are aware that you have to specially take care of any field or event declared as static?
Ever since this was added I enabled this for every project I worked in and I've yet to see a single issue that wasn't caused by a static that I needed to take care of. Unfortunately, many store assets are not compatible with disabled domain reload.

CPU is just one part of the equation. Memory and disk (specifically: fast SSD) and motherboard (think: PCIe3/4 SSD) make a big diff.

You may actually get a big speed increase with your current system if you take some time and look for ways to optimize your project. This could be cleaning up assets, removing excess packages/modules, profiling in the editor to check for any hotspots. Quite commonly, badly written editor scripts slow down the editor. One very common cause that is typically used without ever thinking about it: calling AssetDatabase.Refresh() in the wrong places and too often.

 

My current Win configuration: i7 12th, 64GB RAM, nvidia 3700TI 8GB, samsung M2 2TB SSD, and every 2022.x is slow as hell when loading every damn project.

 

I‘m sorry I am not familiar with measuring time in units of „hell“. Put a number to it, and how that number has changed compared to the previous Unity version you used, and also provide the exact Unity versions. Then we can see if there is anything that can be done about it.

 

I have 2 projects to compare, a 2GB project on 2018.4, a 6GB project on 2022.1. So 2022.1 should take longer to open, because there are more assets. Let's compare: I open a project, then:
2 seconds for splash image to appear on 2018.4. 10 seconds on 2022.1. 1 minute passed: 2018.4 opened it's project, 2022.1 still refreshes the asset DB. 2 minutes passed, it finally opened the project (and sometimes it could take even 3-4 minutes)
Now to the performance in the editor itself: I want to delete an asset. Unity 2018.4 will immidiately bring the dialog window. 2022.1 on the other hand:
Now for instance I want to pick a material/texture/mesh: 2018.4 does it fine, but in 2022.1: it takes a few seconds to load the window, and I can barely scroll because it's so laggy, and I constantly get this: . Btw the "advanced" picker is even worse
And in many other aspects 2020+ versions are so slow, and it's not the "hold on" window fault, but the editor itself, and it cancels out all the nice improvements they did...

 

You can't compare apples with oranges.

Take a copy of that 2018 project and make it run in 2022 even if that means disabling some code or whatever. Then you can compare them on an equal footing.

It takes just a single badly written editor script to bring down the Unity editor to a crawl, specifically with a growing number of assets. While Unity itself has some ups and downs regarding performance in every area over time, the number one cause for slow Unity projects is most often found in the project itself in my experience.

 

I made a copy of that 2018.4 project, upgraded it to 2022.1, deleted the library folder of both, opened them, fixed errors and removed a few redundant packages in 2022, and restarted the PC.
I admit the start up time didn't differ much (1:10 for 2018.4, 1:15 for 2022.1), but the actual editor performance? Still very very slow for 2022.1, same issues as described in my previous post

 

My system (5950X, 64GB DDR4-3600, 3x 2TB PCIe 3 SSDs) has a typical compilation time of 3 seconds for a completely empty project and 6 for my heaviest project (30GB assets w/ 100GB library). Unity 2022 LTS.

I've never bothered to test the load time as barring crashes I only load the project once per day, but if I don't think it took more than a minute assuming I didn't have to generate new files for the library which I almost always did.

For anyone that isn't aware you can measure the performance of the editor using the Editor Iteration Profiler.

https://forum.unity.com/threads/introducing-the-editor-iteration-profiler.908390/

 

Hi, thanks for telling about this tool! I used it and found something weird... it took 11 seconds to display the deletion confirmation window, and during that it took 6 seconds to read a completely unrelated asset... I wonder how I can continue solving the slowness after I know that. 1000+ calls to the same unrelated asset, something is so weird here :O

 

The first of my bug reports got through:

https://issuetracker.unity3d.com/issues/regression-menu-dot-undo-call-performance-downgrade

Please vote on it

 

It feels like every new version of Unity Editor is worse and worse.
Simple tasks like selecting a material will take several minutes if you have 20+ materials in project.
Searching the scene, if you have 100+ objects on it will most likely crash the editor.
All of this is happening on very powerful desktop machine with 64 GB of RAM and latest Ryzen CPU, dedicated Graphics Card with additional 12 GB of VRAM.
I can't imagine working with Unity with some average laptop.

I would love to call it anything else, but Unity Editor is a peace of S***.
I can't wait to finish the current project and say goodby to Unity forever.

 

@IJM Don’t let your feelings get the better of you. The frustration is understandable but if you value your time and your project, you should stop ranting and start analyzing. Open the profiler, enable deep profile and editor profiling, and check where the time is spent on when you select that material.

Far more likely than this being a Unity issue it will boil down to one of these in my experience:

a) an editor script that you are using or wrote yourself
b) heavy asset usage (count, complexity) and/or many packages/assets installed
c) many open windows that are all visible (even if off-screen) and are all updating simultaneously, possibly every frame, possibly pronounced by large lists or nested structs that take a long time to render in the GUI
d) a general system config issue, such as antivirus crapware or other background tasks

Feel free to open a new thread and ask for assistance in resolving this issue.