Unity seem to be extremely slow when making changes to scripts, or trying to run with VS debugging.

Why is Unity so slow?

And which CPU is recommended for making development with Unity editor work faster?

Is a Ryzen better? Or maybe a single core speed is more important, in which case the 12900k will be the best for Unity?

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.