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

Zurtan · 2021-10-27T12:45:27

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?

Engines and Middleware Programming

Started by Zurtan October 23, 2021 01:21 PM

11 comments, last by Shaarigan 3 years ago

Juliean

7,368

October 26, 2021 06:00 PM

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.

Shaarigan

1,471

October 27, 2021 10:25 AM

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

Juliean

7,368

October 27, 2021 10:37 AM

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).