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