Why is Unity so slow and which CPU is recommended to work with Unity editor?

One of the main things that makes Unitys editor so slow is the fact that its based mainly on C#, and C# can only execute via JIT. I've confirmed/found that out via their editor-profiler - most of the time spent after changing scripts etc… is first having to compile the C#, and then the JIT having to recompile (what I assume to be) everything, before the editor can resume running.

For attaching the debugger, I'm not a 100% sure. It seems to be related to having to load the different symbols, but thats mainly a guess (sometimes my debugger just entirely hangs itself even if I let it run for 30 minutes).

As for CPU - IDK, I have a 9900X at home, it is faster than my crappy laptop at the company, but even then, certain hangs are still present. So for what you are experiencing, CPU might not even make that much of a difference.

I would say both intel and Ryzen CPU's are very good.. But there is a catch… you need a high-quality CPU... such as AMD Ryzen 9 5900X Twelve Core or Intel Raptor Lake Core i9-13900K.. but you do not need to buy these exact same CPUs I specified... I specified these because they had the highest performance compared to others. As for myself, I have an AMD Ryzen 7 4800h Eight Core with Radeon graphics and 16gb ram and my unity performance is awesome! The CPU I have is relatively cheaper than the others in price but very nice in quality. Hope this helps.

Juliean said:
One of the main things that makes Unitys editor so slow is the fact that its based mainly on C#, and C# can only execute via JIT. I've confirmed/found that out via their editor-profiler - most of the time spent after changing scripts etc… is first having to compile the C#, and then the JIT having to recompile (what I assume to be) everything, before the editor can resume running

That's not true! Yes, it uses C# but C# in isn't meant to be slow in general, it is more the way Unity handles the C# project. If you recompile the code then depending on how many Assemblies Unity creates, the code is rebuild from scratch and then loaded. This takes a few milliseconds on an avarage development machine. Then Unity starts to analyze all thecomponents you defined in code and matches those to components attached to scene objects and loads serialized properties to be set to every single component instance.

Not to say that they use a custom Roslyn compiler lokated in the Unity install folder.

Unity also hasn't any good dependency management, they just add every single assembly into every other assembly, regardless of if it is used. So you have round about 20 dependency assemblies in a single C# project.

Then it also depends on if you have Burst code enabled, this is another step after compiling the C# code using Roslyn, LLVM is triggered to analyze the generated IL and Burst compiler is called to convert the C' code into something running in parallel.

So one could say, it isn't the compilation process itself but all the analyzis Unity does which is slow

Juliean said:
For attaching the debugger, I'm not a 100% sure. It seems to be related to having to load the different symbols, but thats mainly a guess (sometimes my debugger just entirely hangs itself even if I let it run for 30 minutes).

Debugging is done via TCP connection (you can attach a Visual Studio instance to a running Unity game on another device for example Android) and since network is involved, even if you run it on local machine, this is slower than a native C# debugger

Zurtan said:
And which CPU is recommended

Doesn't matter as Unity is a crappy written piece of software! You can however do some optimization in your project to make it faster.

On emajor tipp is to separate everything into small but not too small Assemblies via Assembly Definition files. If you don't need to recompile the entire priject but some portions which involve Editor code, it is much faster in opposite to having every code file in the default Assembly

Shaarigan said:
That's not true! Yes, it uses C# but C# in isn't meant to be slow in general, it is more the way Unity handles the C# project. If you recompile the code then depending on how many Assemblies Unity creates, the code is rebuild from scratch and then loaded. This takes a few milliseconds on an avarage development machine. Then Unity starts to analyze all thecomponents you defined in code and matches those to components attached to scene objects and loads serialized properties to be set to every single component instance.

I'm not saying C# is meant to be slow, but having to execute a JIT-compiler all the time is going to make startup-times slower than in a language like Java which runs code in a VM to start with.
This is probably less noticable on a normal-sized app-startup, but in a large codebase like Unity (where it not only needs to JIT the user code, but the whole editor), this does add up - again, this is what I actually saw in the profiler, on top of everthing else Unity does (like what you describe), it actually shows the JIT-compiler as a major factor for the time it takes.

Google up how to speed up and improve performance by rearranging your project layout to reduce the amount of compiling that needs to happen after small changes etc

I agree the debugging set up is a bit shit, needs some focus and streamlining by the development team. Its very clunky.

Juliean said:
but having to execute a JIT-compiler all the time is going to make startup-times slower

I don't think this is really necessary ALL the time but on first run of the assembly. However, it won't explain why the Editor itself is slow because JIT should cache the assembly right once it was JIT-ted. Don't know if Unity made their own JIT, in this case no one could say if it can keep on the performance of native Mono/.NET

Shaarigan said:
I don't think this is really necessary ALL the time but on first run of the assembly. However, it won't explain why the Editor itself is slow because JIT should cache the assembly right once it was JIT-ted. Don't know if Unity made their own JIT, in this case no one could say if it can keep on the performance of native Mono/.NET

No, it doesn't explain all the slowness - I was directly targeting it at OP noticing slowdowns when scripts are recompiled.

As for the caching - it appeared to me as such, that the assembly is actually cached when first run. However, it seems that every time any of the assemblies are recompiled, the JIT is rerun for the entire application. Not sure if this is an absolute hard technical limitation of C# or just a quirk in unitys implementation, but thats at least what I was able to profile. It might have something to do with the way unity is setup, and the way user-scripts can extend the editor.

Also no, this is just the standard C#-JIT. Unity didn't even bother including 64-bit mono, for runtime-performance they now have IL2CPP which is the de-facto standard and recommended to be used for all platforms (and required for most). So outside of the editor, the C#-speed has little impact anymore unless you are targeting desktop and can't or don't want to use IL2CPP.

“slow” can mean many things. It's not just dependent on the CPU.

Do you have enough RAM?

Do you have a fast SSD?

Do you have a fast graphics card?

What operations are slow, and what is the bottleneck in those operations? Once you've identified these, you can start figuring out what to do about it.

@hplus0603 I am not talking about performance of the app that Unity builds.

I am talking about the editor itself.

My PC is a Ryzen 7 2700X, with NVME Samsung SSD, 64 GB of Ram, and RTX 2080.

Zurtan said:
I am talking about the editor itself.

FWIW, you could try to run the editor-profiler yourself (https://forum.unity.com/threads/introducing-the-editor-iteration-profiler.908390/)​ and see if you find anything. This does require a certain amount of background-knowledge to be able to make sense of it, and even then it might not yield much. But it could be worth a shot so I thought I'd mention it.

Juliean said:
As for the caching - it appeared to me as such, that the assembly is actually cached when first run. However, it seems that every time any of the assemblies are recompiled, the JIT is rerun for the entire application. Not sure if this is an absolute hard technical limitation of C#

Spoiler, it isn't! I'm developing all of our tools in C# and running even a big one assembled from a lot of code modules, it has a slow startup at first run but then CLR is caching everything and unless you change something, even a recompile still results in a very good startup time after the first optimization has happened. So it must be Unity and/or the mono runtime they use.

Juliean said:
Also no, this is just the standard C#-JIT. Unity didn't even bother including 64-bit mono, for runtime-performance they now have IL2CPP which is the de-facto standard and recommended to be used for all platforms (and required for most). So outside of the editor, the C#-speed has little impact anymore unless you are targeting desktop and can't or don't want to use IL2CPP

I don't agree for having to use IL2CPP in general as either you use C# and all of it's benefits or you use C++ and it's benefits but using an IL analyzer which doesn't even support features C# has uniquely (like on-demand IL generation), then you're using the wrong platform! Anyways, they're doing it and it makes more trouble then its worth sometimes

Shaarigan said:
Spoiler, it isn't! I'm developing all of our tools in C# and running even a big one assembled from a lot of code modules, it has a slow startup at first run but then CLR is caching everything and unless you change something, even a recompile still results in a very good startup time after the first optimization has happened. So it must be Unity and/or the mono runtime they use.

Ok, interesting. I mean its no suprise, unity is in itself pretty inefficient in pretty much all regards.

Shaarigan said:
I don't agree for having to use IL2CPP in general as either you use C# and all of it's benefits or you use C++ and it's benefits but using an IL analyzer which doesn't even support features C# has uniquely (like on-demand IL generation), then you're using the wrong platform! Anyways, they're doing it and it makes more trouble then its worth sometimes

Oh I don't necessarily agree with their decision to use IL2CPP exclusively eigther. For one, it increases the build-times dramatically (which can already be pretty bad, especially compared to unreal where you can do a soft-launch from inside the editor), and it can indee cause problems. We had a case where in combination with Bolt+IL2CPP a project would throw some exceptions on startup that could only be resolved by rewriting the affected bolt script to C# again (now bolt is a thing for itself, but it at least didn't produce such critical issues with the mono-framework).

Yeah, we see a lot of errors in the VR project I'm involved in at work