IL2CPP runtime performance improvements in Unity 2021.2 | Hacker News Reader

IL2CPP runtime performance improvements in Unity 2021.2

blog.unity.com

49 pointspjmlp12 comments

I really admire and appreciate the engineering that Unity has put into IL2CPP. Mono has a full AOT option[1], but I believe that IL2CPP predates it. I just remembered that on an episode of The Changelog[2], Miguel de Icaza (the creator of Gnome, Mono, and Xamarin) mentioned that Unity hired a developer from the Mono team to develop the first version of IL2CPP for them after Apple suddenly stopped allowing JIT on iOS[3].

[1]: https://www.mono-project.com/docs/advanced/aot/#full-aot

[2]: https://changelog.com/podcast/275

[3]: https://changelog.com/podcast/275#transcript-54

IIRC it was a bit more convoluted than that. Unity was using Mono AOT for iOS at the time when Apple announced that iOS was moving to ARM64, I think Mono already supported ARM64 AOT but Unity was stuck on an old version which was 32bit only because they were unwilling to pay whatever Xamarin was charging for the new version (Mono had a dual license like QT back then).

IL2CPP was originally developed for the WebGL build target (pre web assembly it went .NET -> cpp -> javascript). After the Apple announcement it was hastily ported to work on iOS. Initially (and maybe up to a couple of years afterwards to some degree ) it was extra buggy and the build time was extremely slow, but I think it was probably worth it in the end.

Not quite also.

IL2CPP first target were game consoles.

That's really interesting. I had tried to find a history of IL2CPP on the web but didn't get any Google hits, so thank you for sharing these details!

All of these operations are so much faster in Microsofts C# (10x - 100x) than it is in the mono used by Unity. Is there really no way to use Microsofts C# here? From what I understand both use the same base C# runtime so it is mainly thanks to better written libraries and code generation, so should help even with IL2CPP.

Stuff like boxing/unboxing, calls using delegates, calling native code, using reflection etc are all much faster in Microsofts version.

.NET Core doesn't run in game consoles, and they still rely on Mono for mobile devices.

Yes, but that’s not because it’s impossible… just because unity decided to reengineer an entire language in house to build their product.

Unfortunately, the reality is that Microsoft has more engineers and money devoted to this problem than unity possibly can, so the official c# runtime will continue to support more platforms and being new feature and better performance at a pace that is…

…categorically not possible…

For unity to match.

So… while it’s a bitter pill to swallow, and it was done for reasons that seemed good at the time, it was the wrong choice, and that will become increasingly clear as time rolls on.

There’s what I believe is a pretty classic case of sunk cost fallacy going on with a number of current initiatives in the Unity ecosystem.

Some companies thrive under competition. Some… do not.

Except Microsoft is not spending any of their engineers making .NET run on PlayStation, Nintendo or XBox (.NET Native is a bastardised version and UWP is deprecated on the XBox anyway).

Likewise in what concerns iOS, Android and WebAssembly, those same engineers keep using Mono runtime, as apparently there aren't as many resources as you paint.

A good example of the resourcing problem is the ongoing tragedy of migrating the development from UWP into WinUI 3.0/AppSDK

The Microsoft C# compiler team is actually quite small. And the Microsoft C# compiler doesn’t support consoles so no comparison.

whole lot of fuss over nothing. still takes 30 seconds hanging when compiling script changes. I don't care if the flag check is 100 nano seconds faster if I can't work.

IL2CPP is separate concern from how fast Unity performs in editor. Our best hope for better editor performance is they move the editor to modern dotnet, and it's actually quite possible this happens by 2023 cyclus [1]

For domain reload performance, 30s seems really a lot, I suggest you profile InitializeOnLoad calls in the editor - some 3rd party plugins have a nasty habit of clogging domain reload with stupid "check for updates" http calls and similar junk, I found it rather easy to clean up.

[1] - https://forum.unity.com/threads/unity-future-net-development...

Not my experience at all. Unity is super fast compiling script changes (sub-second).

Reply on news.ycombinator.com