20 ms·

Unity's Mono problem: C# code runs slower than it should

279 points by iliketrains 9mo ago

makotech221 9mo ago
Yeah I think Unity just doesn't have the technical skillset anymore to make the migration to coreclr. It keeps getting delayed and their tech leads keep dropping out. Might I suggest https://github.com/stride3d/stride https://github.com/stride3d/stride, which is already on .net 10 and doesn't have any cross-boundary overhead like Unity.
- WillPostForFood 9mo ago
  Progress has been painfully slow, but Unity does seem to be moving forward. Unity updates on their plans and progress: 2022 - officially announced plans to switch to CoreCLR - https://unity.com/blog/engine-platform/unity-and-net-whats-next https://unity.com/blog/engine-platform/unity-and-net-whats-n... 2023 - Tech update - https://unity.com/blog/engine-platform/porting-unity-to-coreclr https://unity.com/blog/engine-platform/porting-unity-to-core... Unite 2025 - CoreCLR based player scheduled for Unity 6.7 in 2026 - https://digitalproduction.com/2025/11/26/unitys-2026-roadmap-coreclr-verified-packages-fewer-surprises/ https://digitalproduction.com/2025/11/26/unitys-2026-roadmap...
  - teraflop 9mo ago
    Maybe they are making progress. But given that they first started talking about this in 2018, and then in 2022 they announced that they were planning to release a version with CoreCLR in 2023, and then in 2024 they said it would be in beta in 2025, and now in 2025 they're planning to release it as a technical preview in 2026, but they're still talking about an "internal proof-of-concept" as though it's something coming in the future... As an outsider, it certainly seems like there's reason for skepticism.
    - cheschire 9mo ago
      Well they made some business decisions in the middle of that timeline that cut their funds quite a bit, not to mention probably scared off some good talent.
      - chris_wot 9mo ago
        Scared off a lot of customers, too.
      - ACS_Solver 9mo ago
        Not just probably scared off some good talent, they had xoofx leave over disagreements with higher management. xoofx was one of their most senior devs, the guy who started the CoreCLR migration and was leading it. They'll get there eventually, but the current roadmap says experimental CoreCLR in late 2026, which then in the best case means production ready in 2027. Unity isn't going anywhere, but at least as a dev who doesn't care about mobile (which is Unity's real market), competing engines have gotten much more attractive in the last couple years and that seems set to continue.
        whstl 9mo ago
        The funny thing about his resignation is that xoofx had a CoreCLR prototype already working around 2016-ish, but the company had "other priorities" and only took it seriously until recently. The guy should just have been left alone and shielded from company bullshit to do the migration, or empowered to fight. I know this is one sided but: Whoever from high-management lost this guy is an absolute loser waste of space who didn't do his job and will blame xoofx for “not fighting harder” or some other bullshit. Fuck companies, and fuck loser managers.
        ACS_Solver 9mo ago
        I think 2016 is a bit too early but yeah, xoofx first wrote about CoreCLR in 2018 and said he'd made considerable progress with something like himself and two other engineers doing it as a side project. That is four years before Unity as a company announced the migration as a priority, which in turn is another four years before the current estimate for when they may ship it. From my perspective, Unity seems very poorly managed in recent years. The editor experience isn't improving while they continue the usual pattern of shipping features in a poor state where they need another couple versions to become properly usable, and of course they make terrible decisions like the runtime fee, a total insanity that caused a huge loss of trust and boosted Godot development enormously. Of course my perspective is biased by me not being Unity's main target market. I work on PC strategy games, which are on Steam. At our studio, we don't do mobile, advanced graphics features aren't very relevant, and we may have the most complex UI that ever shipped in a Unity game.
    - whstl 9mo ago
      I've seen similar things from the inside in other companies. Even existential threats (like lack of Apple Silicon support for performance-critical software), getting heavily delayed because the feature treadmill won't stop and the actually important thing is a pet project of some engineer. It is basically death by a thousand papercuts, where nobody can say what the focus is. People complain about web development but working with native apps can be depressing sometimes.
  - bentt 9mo ago
    Nice link, thanks.
- 999900000999 9mo ago
  Stride has a fraction of the features as unity. Godot is the only real open source competitor, their C# support is spotty. If I can't build to Web it's useless for game jams as no one should be downloading and running random binaries. A real sandbox solution with actual GPU support is needed.
  - eole666 9mo ago
    Godot 4 C# web export is coming soon : https://github.com/godotengine/godot/pull/106125 https://github.com/godotengine/godot/pull/106125
    - 999900000999 9mo ago
      We'll see when it actually ships. I've seen this issue before, they're making progress but theirs no firm release date. Plus you then have to extensive testing to see what works in Web builds and what doesn't. I REALLY enjoy vibe coding in Godot, but it's still behind Unity in a lot of ways.
      - ramon156 9mo ago
        Naive question but why not use GDscript? I haven't had any issues with it
        999900000999 9mo ago
        I'll vibe code stuff in GDscript, and I guess I more or less understand some of it. But C# is what I've used for over a decade. C# has vastly better IDE support. It's a more complete language. Plus a lot of C# assets/libraries don't really have GDScript counterparts.
        eole666 9mo ago
        I'll add that C# have better performances than gdscript. It doesn't make a difference for most of the things you code in a game, but it comes in handy when needed.
- darubedarob 9mo ago
  Imagine you have to communicate that rewrite and drop of support for bought "addons" to the people who went on that shopping spree. Who then would have to explain the "wecan"-value drop + cost of recovery of the same abilities to the shareholders and customers. The magpiesnest of bought companies tech is a tarbaby for any tech lead, the rewrite a career ender for the CEOs office.
- linguistics__ 9mo ago
  > Yeah I think Unity just doesn't have the technical skillset anymore It's not a technical skillset issue, it's a case of lacking resources, leadership changing priorities and changing requirements mid-development, causing a lot of work to be redone. We still have highly skilled developers working in this area, if we can just actually be allowed to do (and keep) we work we have.
Rochus 9mo ago
That's interesting. I made measurements with Mono and CoreCLR some years ago, but only with a single thread, and I came to the conclusion that their performance was essentially the same (see https://rochus.hashnode.dev/is-the-mono-clr-really-slower-than-the-coreclr https://rochus.hashnode.dev/is-the-mono-clr-really-slower-th...). Can someone explain what benchmarks were actually used? Was it just the "Simple benchmark code" in listing 1?
- eterm 9mo ago
  What's going on with the Mandelbrot result in that post? I don't beleive such a large regression from .NET framework to CoreCLR.
  - to11mtm 9mo ago
    NGL would be nice if there was a clear link to the cases used both for OP as well as who you are replying to... Kinda get it in OP's case tho.
    - Rochus 9mo ago
      I measured the raw horsepower of the JIT engine itself, not the speed of the standard library (BCL). My results show that the Mono engine is surprisingly capable when executing pure IL code, and that much of the 'slowness' people attribute to Mono actually comes from the libraries, not the runtime itself. In contrast, the posted article uses a very specific, non-standard, and "apple-to-oranges" benchmark. It is essentially comparing a complete game engine initialization against a minimal console app (as far as I understand), which explains the massive 3x-15x differences reported. The author is actually measuring "Unity Engine Overhead + Mono vs. Raw .NET", not actually "Mono vs. .NET" as advertized. The "15x" figure comes very likely from the specific microbenchmark (struct heavy loop) where Mono's optimizer fails, extrapolated to imply the whole runtime is that much slower.
      - eterm 9mo ago
        Can we reproduce your results for Mandelbrot?
calebh 9mo ago
Will the move to CoreCLR give any speed ups in practice if the release build is complied with IL2CPP anyway? On all the games that I've worked on, IL2CPP is one of the first things that we've enabled, and the performance difference between the editor and release version is very noticeable.
- Rohansi 9mo ago
  Editor is slower than Mono release builds. You'll need to compare Mono release vs. IL2CPP release to see the actual difference.
  - calebh 9mo ago
    I guess it would be good to also see a comparison between IL2CPP and Core CLR by the post author!
Rohansi 9mo ago
The article doesn't cover it but the GC being used by Unity also performs very poorly vs. .NET, and even vs. standalone Mono, because it is using the Boehm GC. Last I heard Unity has no plans to switch IL2CPP to a better GC [1]. It'll be interesting to see how the CoreCLR editor performs. With that big of a speed difference the it might be possible for games to run better in the editor than a standalone Mono/IL2CPP build. [1] https://discussions.unity.com/t/coreclr-and-net-modernization-unite-2024/1519272 https://discussions.unity.com/t/coreclr-and-net-modernizatio...
- Rochus 9mo ago
  > because it is using the Boehm GC For what reason? Mono has a pretty good precise GC since many years.
  - Rohansi 9mo ago
    Yes, SGen should be a lot better, but Unity cannot use it because they hold and pass raw pointers around everywhere. That's fine for Boehm but not possible with SGen. They're working on fixing this already but not sure why they aren't planning a move to a better GC.
    - LeFantome 9mo ago
      Well, if they port to .NET (CoreCLR), that will move them to the MS GC.
      - Rohansi 9mo ago
        Yes, but it also puts them in an awkward situation! They recommend (or even require, for some platforms) using IL2CPP for release builds which will still use Boehm GC and not run as quick as CoreCLR.
        DoctorOW 9mo ago
        Do they still need IL2CPP if they have AOT? The goal was always to be able to have cross-platform native binaries right?
Inityx 9mo ago
[flagged]
- llmslave2 9mo ago
  You think? Seems human to me...
  - yunnpp 9mo ago
    It's not AI, here's why: (yup, LLM-style pun intended) 1. Uses "I" 2. Look how many times it switches verb tenses here: "One day I was debugging an issue in map generation and it was time-consuming [...]. To make debugging faster, I’ve written a unit test, hoping to cut down on the turn-around time since Unity takes 15+ seconds just to crunch new DLLs [...]. When I ran the test, it finished in 40 seconds."
    - CodeCompost 9mo ago
      It's called a grammar mistake. People make them all the time, that's why editing is a job.
      - yunnpp 9mo ago
        I'm not criticizing their mistakes. I'm saying you can tell the writing is human precisely because of them.
sieep 9mo ago
I recently started learning Godot and learning that they use .NET for the C# runtime is a nice touch. I write a lot of code that targets .NET in my day job, so having to learn the unity way of doing things would be frustrating.
boguscoder 9mo ago
Good article but seems strange that author benchmarked debug builds first, that’s a huge “no-no” in any perf tweaking and it’s clear that authors knows this well
- iliketrains 9mo ago
  From my experience, performance gains seen in Debug builds in Unity/C#/Mono nearly always translate in gains in Release mode. I know that this is not always true, but in this context that's my experience. Setting up release benchmarks is much more complex and we develop the game in Debug mode, so it is very natural to get the first results there, and if promising, validate them in Release. Also, since our team works in Debug mode, even gains that only speed things up in Debug mode are valuable for us, but I haven't encountered a case where I would see 20%+ perf gain in Debug mode that would not translate to Release mode.
- mort96 9mo ago
  I agreed with you initially, but is it really as big of a deal in C#? I'm used to compiled languages where "debug build" means "no compiler optimisations", aka every operation done with a variable is a memory load + store, trivial functions aren't inlined so even trivial accessors called in a loop carry function call overhead, etc etc. But this is C#, so the JIT presumably optimises just as much in a debug build as in a release build? So in C++ terms, it's really just benchmarking "-O2" instead of "-O2 -DNDEBUG". This seems fine.
1a527dd5 9mo ago
> In 2018, Unity engineers discussed that they are working on porting the engine to .NET CoreCLR Hard task, no doubt. Unity needs to throw everything at this problem. C# in general has gotten insanely fast by default. It's very much worth taking the time to upgrade/update. Whilst we don't compare in size and api surface, it took us a few months to get off 472 and onto dotnet6. But once we were on dotnet6, moving to the LTS after that was relatively painless; usually a few hours of work.
reactordev 9mo ago
Unity has a unity problem. While it’s easy to get in and make something (it’s got all the bells and whistles) it also suffers from the monolith problem (too many features, old code, tech debt). The asset store is gold but their tech feels less refined. It’s leaps and bounds where it was when it started but it still has this empty feel to it without heavy script modifications. There is the problem. The scripting ending designed around mono doesn’t translate as well to CoreCLR and using the same Behavior interface gets a little more complicated. There are times (even with my own engine) that one must let go of the old and begin a new. Dx7->dx9, dx9->opengl, opengl->vulkan, vulkan->webgpu. EDIT I was just thinking, returning to this a couple of minute later, that if Unity wanted to prove they really care about their Core, they would introduce a complete revamp of the editor like Blender did for 3.X. Give more thought to the level editors and prefab makers. Give different workflow views. Editing / Animation / Scripting / Rendering / Post As it stands now, it’s all just a menu item that spawns a thing in a single view with a 1999 style property window on the side like Visual Studio was ever cool.
- DiabloD3 9mo ago
  That last step is nonsensical: WebGPU is a shim layer that Vulkan-like layer (in the sense that WebGL is GLES-like) that allows you to use the native GPGPU-era APIs of your OS. On a "proper OS", your WebGPU is 1:1 translating all calls to Vulkan, and doing so pretty cheaply. On Windows, your browser will be doing this depending on GPU vendor: Nvidia continues to have not amazing Vulkan performance, even in cases where the performance should be identical to DX12; AMD does not suffer from this bug. If you care about performance, you will call Vulkan directly and not pay for the overhead. If you care about portability and/or are compiling to a WASM target, you're pretty much restricted to WebGPU and you have to pay that penalty. Side note: Nothing stops Windows drivers or Mesa on Linux from providing a WebGPU impl, thus browsers would not need their own shim impl on such drivers and there would be no inherent translation overhead. They just don't.
  - reactordev 9mo ago
    I’m foreshadowing a future where they do. Please don’t kill the dream.
pwdisswordfishy 9mo ago
The author (probably unknowingly) glosses over a lot in these sentences of the "How did we get here" section: > Unity uses the Mono framework to run C# programs and back in 2006 it was one of the only viable multi-platform implementations of .NET. Mono is also open-source, allowing Unity to do some tweaks to better suit game development. [...] An interesting twist happened nearly 10 years later. Not mentioned is that Mono itself of course improved a lot over the years, and even prior to MS's about-face on open source, it was well known that Unity was hindered by sticking with an old and out-of-date Mono, and they were very successful at deflecting the blame for this by throwing the Mono folks under the bus. Any time complaints about game developers' inability to use newer C# features came up, Mono/Xamarin would invariably receive the ire* because Unity couldn't come to an agreement with them about their license and consulting fees. (Mono was open source under LGPL instead of MIT licensed at the time, and Unity had initially bought a commercial license that allowed them exemptions from even the soft copyleft provisions in the LGPL, but the exemption was limited and not, for example, for any and all future versions, too, indefinitely.) Reportedly, they were trying to charge too much (whatever that means) for Unity's attempts to upgrade to the modern versions. It's now 10+ years later, and now not only Mono (after being relicensed under MIT) but .NET CoreCLR are both available for Unity at no cost, but despite this it still took Unity years before they'd upgraded their C# language support and to a slightly more modern runtime. Something else to note: Although, LGPL isn't inherently incompatible with commercial use or even use in closed source software, one sticking point was that some of the platforms Unity wished to be able to deploy have developer/publisher restrictions that are incompatible with the soft copyleft terms in the LGPL that require that users (or in this case game developers) be allowed to relink against other versions of the covered software (including, for example, newer releases). Perversely, it's because Unity sought and obtained exemptions to the LGPL that both end users and game developers were hamstrung and kept from being able to upgrade Mono themselves! (It wouldn't have helped on, say, locked down platforms like Nintendo's for example, but certainly would have been viable on platforms without the first-party restrictions, like PC gaming or Android.) By now, Unity has gone on to pull a lot of other shenanigans with their own pricing that seems to have sufficiently pissed off the game development community, but it should still not be forgotten when they were willing to pass the blame to an open source project over the development/support that the company felt it was entitled to for a price lower than they were told it would cost, and that they themselves were slow to make progress on even when the price of the exemption literally became $0. * you can find threads with these sorts of comments from during this period right here on HN, too, but it was everywhere
Rohansi 9mo ago
[flagged]
luaKmua 9mo ago
In general when game development comes up here I tend not to engage as professional gamedev is so different than what other people tend to deal with that it's hard to even get on the same page, but seeing as how this one is very directly dealing with my expertise I'll chime in. There are few things off with the this post that essentially sound as someone more green when it comes to Unity development (no problem, we all start somewhere). 1. The stated approach of separating the simulation and presentation layers isn't all that uncommon, in fact it was the primary way of achieving performance in the past (though, you usually used C++, not C#). 2. Most games don't ship on the mono backend, but instead on il2cpp (it's hard to gauge how feasible that'd be from this post as it lacks details). 3. In modern Unity, if you want to achieve performance, you'd be better off taking the approach of utilizing the burst compiler and HPC#, especially with what appears to be happening in the in sample here as the job system will help tremendously. 4. Profiling the editor is always a fools errand, it's so much slower than even a debug build for obvious reasons. Long story short, Unity devs are excited for the mentioned update, but it's for accessing modern language features, not particularly for any performance gains. Also, I've seen a lot of mention around GC through this comment section, and professional Unity projects tend to go out of their way to minimize these at runtime, or even sidestep entirely with unmanaged memory and DOTS.
- oppo777 9mo ago
  [flagged]
- iliketrains 9mo ago
  Author here, thanks for your perspective. Here some thoughts: > approach of separating the simulation and presentation layers isn't all that uncommon I agree that some level of separation is is not that uncommon, but games usually depend on things from their respective engine, especially on things like datatypes (e.g. Vector3) or math libraries. The reason I mention that our game is unique in this way is that its non-rendering code does not depend on any Unity types or DLLs. And I think that is quite uncommon, especially for a game made in Unity. > Most games don't ship on the mono backend, but instead on il2cpp I think this really depends. If we take absolute numbers, roughly 20% of Unity games on Steam use IL2CPP [1]. Of course many simple games won't be using it so the sample is skewed is we want to measure "how many players play games with IL2CPP tech". But there are still many and higher perf of managed code would certainly have an impact. We don't use IL2CPP because we use many features that are not compatible with it. For example DLC and mods loading at runtime via DLLs, reflection for custom serialization, things like [FieldOffset] for efficient struct packing and for GPU communication, etc. Also, having managed code makes the game "hackabe". Some modders use IL injection to be able to hook to places where our APIs don't allow. This is good and bad, but so far this allowed modders to progress faster than we expected so it's a net positive. > In modern Unity, if you want to achieve performance, you'd be better off taking the approach of utilizing the burst compiler and HPC# Yeah, and I really wish we would not need to do that. Burst and HPC# are messy and add a lot of unnecessary complexity and artificial limitations. The thing is, if Mono and .NET were both equally "slow", then sure, let's do some HPC# tricks to get high performance, but it is not! Modern .NET is fast, but Unity devs cannot take advantage of it, which is frustrating. By the way, the final trace with parallel workers was just C#'s workers threads and thread pool. > Profiling the editor is always a fools errand Maybe, but we (devs) spend 99% of our time in the editor. And perf gains from editor usually translate to the Release build with very similar percentage gains (I know this is generally not true, but in my experience it is). We have done many significant optimizations before and measurements from the editor were always useful indicator. What is not very useful is Unity's profiler, especially with "deep profile" enabled. It adds constant cost per method, highly exaggerating cost of small methods. So we have our own tracing system that does not do this. > I've seen a lot of mention around GC through this comment section, and professional Unity projects tend to go out of their way to minimize these at runtime Yes, minimizing allocations is key, but there are many cases where they are hard to avoid. Things like strings processing for UI generates a lot of garbage every frame. And there are APIs that simply don't have an allocation-free options. CoreCLR would allow to further cut down on allocations and have better APIs available. Just the fact that the current GC is non-moving means that the memory consumption goes up over time due to fragmentation. We have had numerous reports of "memory" leaks where players report that after periodic load/quit-to-menu loops, memory consumption goes up over time. Even if we got fast CoreCLR C# code execution, these issues would prevail, so improved CG would be the next on the list. [1] https://steamdb.info/stats/releases/?tech=SDK.UnityIL2CPP https://steamdb.info/stats/releases/?tech=SDK.UnityIL2CPP
darig 9mo ago
[dead]
LeFantome 9mo ago
It blows my mind that Unity has not been able to migrate to .NET (CoreCLR) after starting back in 2018. I would have estimated a year, or two tops, for that project.
MindSpunk 9mo ago
CoreCLR doesn't help on console platforms because you can't ship the JIT runtime. To my knowledge CoreCLR's AOT solution won't work because of SDK and build requirements for shipping builds on consoles. I believe some consoles require that all shipped native code must have been compiled with the SDK compiler. Even if you fork the CoreCLR AOT system so you can build for the consoles (the code can't be open because of NDAs) you wouldn't be allowed to ship the binary. IL2CPP is the only path forward there. CoreCLR is only viable on PC.
- CyanLite2 9mo ago
  Simply not true, this info is outdated by a decade. CoreCLR NativeAOT is already shipping real games on Nintendo, PS5, and Xbox. JIT isn't allowed on iPhones either, and this is what NativeAOT solves. Also, .NET is moving WASM support to CoreCLR (rather than mono) in an upcoming version as well.
  - MindSpunk 9mo ago
    Do you have examples? As far as I'm aware based on current info there's at least one current console vendor that requires all native code to be generated by their SDK.
    - neonsunset 9mo ago
      Just don't ship to PlayStation and discourage others until Sony changes (is forced to) policy.
      - pjmlp 9mo ago
        Capcom does, and they are quite happy with it.
- pjmlp 9mo ago
  Yes, it does, Capcom is using it for their Playstation 5 games, like Devil May Cry. "RE:2023 C# 8.0 / .NET Support for Game Code, and the Future" https://www.youtube.com/watch?v=tDUY90yIC7U https://www.youtube.com/watch?v=tDUY90yIC7U As always, it is a matter of having the skill to deliver, instead of GC phobia.
BatteryMountain 9mo ago
My dream would be that I can adb into my phone, install the .Net SDK or .Net Runtime (v 8 or 10) and have my applications run natively on Android. Simple console apps first, then the rest. Google should open their platform up a little bit more. Allow us to enable root access via adb. Let us unleash our pocket computer's full potentials. Would love to have portable low powered servers, running stacks of my choice. They are super efficient already, have large storages, I can already plug in a usb-c hub into my phone to get more storage, LAN network, keyboard/mouse, external mic if needed. Running my phone with wireguard/tailscale + some lightweight containers = awesome! Unity really do need to catch up though. .Net 8/10 is really amazing and FAST. With the new garbage collector changes for .Net 10, game stutter would be nearly gone gone. Unrelated point: I basically stream most of my games with Sunlight + Moonlight from my main rig to my phone with a controller attached, so I can play Diablo 2 remastered, Hades, Grim Dawn and basically any game with Xbox controller support, directly on my phone. Works amazingly well. Phones has high dpi screen + 120hz OLED panel and since all rendering happens on my headless gaming server, at highest settings, the phone's battery doesn't really drain at all, can play for hours. Playing a Mono based game from the play store can drain the battery within 2 hours, and the games are usually so badly built for android, even paid games that have equivalents on steam.
- littlecranky67 9mo ago
  > My dream would be that I can adb into my phone, install the .Net SDK or .Net Runtime (v 8 or 10) and have my applications run natively on Android My understanding is that you can (almost) do that using MAUI (formerly known as Xamarin). You will not get a .Net SDK or Runtime, but the mono runtime. Since it is bundled in your app, you won't actually notice.
  - BatteryMountain 9mo ago
    No, we need one level lower & zero mono. I want the sdk or runtime to be installed in the same way (and executable) the same way on android as on other linux distro's. .Net has ARM builds so it will work fine. This is without any specific framework dependencies (like aspnet, maui, avalonia etc) - just plain .net 8/10. It would actually be nice if android just bundled the runtime to begin with so we don't have to. They can just pin it to latest LTS versions and let it auto update now & then, same way as WebView/Google play services etc.
LarsDu88 9mo ago
Ah I wonder if this could've saved me countless hours of optimizing my VR game Rogue Stargun for the Quest 2, particularly the final battle in the game
NooneAtAll3 9mo ago
my main problem with Unity games is never the speed - it's the outrageous RAM usage
skrebbel 9mo ago
Does anyone on here know why it is that Unity doesn't just run on .NET? The cross-platform benefits of Mono have disappeared a decade ago or something like that. Like, why would Unity invest in hacks like il2cpp rather than just port over to modern .NET? Is there some licensing thing going on?
- rincebrain 9mo ago
  The article touches on it - assuming it's correct, it's because they did a bunch of proprietary modifying on Mono, so it's not "just" Mono any more, it's Mono and a decade or more of the most exciting layer violating crimes you can imagine. I would assume, if someone Meta scale had an app that had to be built on Unity for whatever reason, we'd see similar blogposts to the ones they did about finding bespoke optimizations for their Android app to be performant with how enormous it became, probably involving either some bespoke alternative to IL2CPP, or writing a bunch of bespoke optimizations onto a bastard descendant of whatever version of Mono Unity originally derives from and so supports...or just paying Unity so much money they get to do whatever they want to the underlying source.
  - tyleo 9mo ago
    I’ve heard (but don’t have an inside source) that Meta’s Horizon was built on Unity and then ported to a custom engine implementation.
- WorldMaker 9mo ago
  Sunk cost fallacy will be a big factor. They already invested a lot of money/time into customizing Mono and hacks like Burst and IL2CPP, so there's momentum to "stay the course" and continue investing in those. Even if some evidence suggests that it is the wrong course.
enbugger 9mo ago
Not to mention the Hot Reload which comes out of the box.
tyleo 9mo ago
I wrote the Circuits programming system for Rec Room, and we took a similar approach: keeping the core logic free of Unity dependencies so it could run and be tested on CoreCLR. The results were similar as well with significantly better performance outside of Unity. There are also secondary benefits. Unity’s API surface is huge, and it’s easy for code to accidentally entangle itself with engine details in ways that confuse or constrain other developers. By isolating the core in a separate DLL, we only expose Unity concepts where they’re actually needed, and we enforce that boundary with tests. That logic constraint ended up being just as valuable as the performance gain
KronisLV 9mo ago
It's cool to see detailed traces and flame graphs be used more often! A lot of different problems could be detected if they were available for pretty much any language, with enough details and tooling to be useful. Heh, I remember also using VisualVM for finding issues with a web app HTTP thread pool and later with the SQL queries being executed (and also the DB pooling solution).
viktorcode 9mo ago
I wonder why the author doesn't use IL2CPP and sticks to Mono. IL2CPP does produce much faster code, making Mono builds obsolete. This should be the very first step you do if you care at all about performance in Unity.
kkukshtel 9mo ago
Wanted to chime in here with some thoughts/clarifications as I'm the Enginnering Manager of the VM team at Unity, aka the team that is leading the charge on .NET Modernization and the CoreCLR transition (and also owns IL2CPP). Also speaking here as myself and obviously not on behalf of the company. First thing is that CoreCLR is _very_ much an active development effort and we're committed to the roadmap we presented at Unite, with at least a CoreCLR-backed Player (aka, what you "Build" when you build your game with Unity) being delivered as a technical preview around the 6.7 release timing. This would basically mean being able to select "CoreCLR" as a scripting backend option (similar to IL2CPP) and see some of the upside and benefit the author mentions here. That said, Unity isn't a pure C# environment. As lots of people know, there is a robust native layer underlying a lot of the managed (C#) code operating a pseudo-ECS design (not literally DOTS/Entites but an engine architecture thing). This means that a lot of the load-bearing code Unity-the-engine is running every frame is notably _not_ C# code, but instead native code that is, in a lot of cases, already very fast. This means that for tight loops of certain systems in the engine, moving to modern .NET isn't going to carry an implict performance increase of those systems. Said differently, CoreCLR isn't a magic performance bullet for Unity. What we like to say though is that "CoreCLR will make C# code faster", so if your game (or general scripting architecture like the author brings up, with lots of "loose" C#) is very C# dependent, you _will_ see a lot of benefit. One thing we starting to investigate is how much performance there is to gain in Unity-the-engine by migrating legacy native C++ code to C# backed by CoreCLR. C# code can be a lot more maintainable and I'd be lying if I said that we really need _every_ managed->native->managed jump we do in the engine, especially with the performance benefit CoreCLR gives us. There are additional things as well like getting intrinsic-backed (or JIT'd) SIMD code for any C# we write with apis like Span<T>, covering for plenty on places in native code where we aren't directly checking for processor arch at runtime or the compiler misses some optimization. This is especially relevant as we also move the editor to CoreCLR, and obviously want it to be as fast as possible, and represents some of the attendant benefits of really focusing on .NET modernization. Regardless, CoreCLR is very much the future of Unity and we're all very excited about it and the progress we're making. The player in 6.7 is the first step and there are lots of other parts (like modern C# lang versions) that will be major boons to development writ large. I (personally, as a game developer) see a lot of awesome things possible downstream of the shift and am (again, selfishly) very excited about what's possible.

279 points by iliketrains 9mo ago

Yeah I think Unity just doesn't have the technical skillset anymore to make the migration to coreclr. It keeps getting delayed and their tech leads keep dropping out. Might I suggest https://github.com/stride3d/stride https://github.com/stride3d/stride, which is already on .net 10 and doesn't have any cross-boundary overhead like Unity.

WillPostForFood 9mo ago
Progress has been painfully slow, but Unity does seem to be moving forward. Unity updates on their plans and progress: 2022 - officially announced plans to switch to CoreCLR - https://unity.com/blog/engine-platform/unity-and-net-whats-next https://unity.com/blog/engine-platform/unity-and-net-whats-n... 2023 - Tech update - https://unity.com/blog/engine-platform/porting-unity-to-coreclr https://unity.com/blog/engine-platform/porting-unity-to-core... Unite 2025 - CoreCLR based player scheduled for Unity 6.7 in 2026 - https://digitalproduction.com/2025/11/26/unitys-2026-roadmap-coreclr-verified-packages-fewer-surprises/ https://digitalproduction.com/2025/11/26/unitys-2026-roadmap...
- teraflop 9mo ago
  Maybe they are making progress. But given that they first started talking about this in 2018, and then in 2022 they announced that they were planning to release a version with CoreCLR in 2023, and then in 2024 they said it would be in beta in 2025, and now in 2025 they're planning to release it as a technical preview in 2026, but they're still talking about an "internal proof-of-concept" as though it's something coming in the future... As an outsider, it certainly seems like there's reason for skepticism.
  - cheschire 9mo ago
    Well they made some business decisions in the middle of that timeline that cut their funds quite a bit, not to mention probably scared off some good talent.
    - chris_wot 9mo ago
      Scared off a lot of customers, too.
    - ACS_Solver 9mo ago
      Not just probably scared off some good talent, they had xoofx leave over disagreements with higher management. xoofx was one of their most senior devs, the guy who started the CoreCLR migration and was leading it. They'll get there eventually, but the current roadmap says experimental CoreCLR in late 2026, which then in the best case means production ready in 2027. Unity isn't going anywhere, but at least as a dev who doesn't care about mobile (which is Unity's real market), competing engines have gotten much more attractive in the last couple years and that seems set to continue.
      - whstl 9mo ago
        The funny thing about his resignation is that xoofx had a CoreCLR prototype already working around 2016-ish, but the company had "other priorities" and only took it seriously until recently. The guy should just have been left alone and shielded from company bullshit to do the migration, or empowered to fight. I know this is one sided but: Whoever from high-management lost this guy is an absolute loser waste of space who didn't do his job and will blame xoofx for “not fighting harder” or some other bullshit. Fuck companies, and fuck loser managers.
        ACS_Solver 9mo ago
        I think 2016 is a bit too early but yeah, xoofx first wrote about CoreCLR in 2018 and said he'd made considerable progress with something like himself and two other engineers doing it as a side project. That is four years before Unity as a company announced the migration as a priority, which in turn is another four years before the current estimate for when they may ship it. From my perspective, Unity seems very poorly managed in recent years. The editor experience isn't improving while they continue the usual pattern of shipping features in a poor state where they need another couple versions to become properly usable, and of course they make terrible decisions like the runtime fee, a total insanity that caused a huge loss of trust and boosted Godot development enormously. Of course my perspective is biased by me not being Unity's main target market. I work on PC strategy games, which are on Steam. At our studio, we don't do mobile, advanced graphics features aren't very relevant, and we may have the most complex UI that ever shipped in a Unity game.
  - whstl 9mo ago
    I've seen similar things from the inside in other companies. Even existential threats (like lack of Apple Silicon support for performance-critical software), getting heavily delayed because the feature treadmill won't stop and the actually important thing is a pet project of some engineer. It is basically death by a thousand papercuts, where nobody can say what the focus is. People complain about web development but working with native apps can be depressing sometimes.
- bentt 9mo ago
  Nice link, thanks.
999900000999 9mo ago
Stride has a fraction of the features as unity. Godot is the only real open source competitor, their C# support is spotty. If I can't build to Web it's useless for game jams as no one should be downloading and running random binaries. A real sandbox solution with actual GPU support is needed.
- eole666 9mo ago
  Godot 4 C# web export is coming soon : https://github.com/godotengine/godot/pull/106125 https://github.com/godotengine/godot/pull/106125
  - 999900000999 9mo ago
    We'll see when it actually ships. I've seen this issue before, they're making progress but theirs no firm release date. Plus you then have to extensive testing to see what works in Web builds and what doesn't. I REALLY enjoy vibe coding in Godot, but it's still behind Unity in a lot of ways.
    - ramon156 9mo ago
      Naive question but why not use GDscript? I haven't had any issues with it
      - 999900000999 9mo ago
        I'll vibe code stuff in GDscript, and I guess I more or less understand some of it. But C# is what I've used for over a decade. C# has vastly better IDE support. It's a more complete language. Plus a lot of C# assets/libraries don't really have GDScript counterparts.
      - eole666 9mo ago
        I'll add that C# have better performances than gdscript. It doesn't make a difference for most of the things you code in a game, but it comes in handy when needed.
darubedarob 9mo ago
Imagine you have to communicate that rewrite and drop of support for bought "addons" to the people who went on that shopping spree. Who then would have to explain the "wecan"-value drop + cost of recovery of the same abilities to the shareholders and customers. The magpiesnest of bought companies tech is a tarbaby for any tech lead, the rewrite a career ender for the CEOs office.
linguistics__ 9mo ago
> Yeah I think Unity just doesn't have the technical skillset anymore It's not a technical skillset issue, it's a case of lacking resources, leadership changing priorities and changing requirements mid-development, causing a lot of work to be redone. We still have highly skilled developers working in this area, if we can just actually be allowed to do (and keep) we work we have.

Rochus 9mo ago

That's interesting. I made measurements with Mono and CoreCLR some years ago, but only with a single thread, and I came to the conclusion that their performance was essentially the same (see https://rochus.hashnode.dev/is-the-mono-clr-really-slower-than-the-coreclr https://rochus.hashnode.dev/is-the-mono-clr-really-slower-th...). Can someone explain what benchmarks were actually used? Was it just the "Simple benchmark code" in listing 1?

eterm 9mo ago
What's going on with the Mandelbrot result in that post? I don't beleive such a large regression from .NET framework to CoreCLR.
- to11mtm 9mo ago
  NGL would be nice if there was a clear link to the cases used both for OP as well as who you are replying to... Kinda get it in OP's case tho.
  - Rochus 9mo ago
    I measured the raw horsepower of the JIT engine itself, not the speed of the standard library (BCL). My results show that the Mono engine is surprisingly capable when executing pure IL code, and that much of the 'slowness' people attribute to Mono actually comes from the libraries, not the runtime itself. In contrast, the posted article uses a very specific, non-standard, and "apple-to-oranges" benchmark. It is essentially comparing a complete game engine initialization against a minimal console app (as far as I understand), which explains the massive 3x-15x differences reported. The author is actually measuring "Unity Engine Overhead + Mono vs. Raw .NET", not actually "Mono vs. .NET" as advertized. The "15x" figure comes very likely from the specific microbenchmark (struct heavy loop) where Mono's optimizer fails, extrapolated to imply the whole runtime is that much slower.
    - eterm 9mo ago
      Can we reproduce your results for Mandelbrot?

calebh 9mo ago

Will the move to CoreCLR give any speed ups in practice if the release build is complied with IL2CPP anyway? On all the games that I've worked on, IL2CPP is one of the first things that we've enabled, and the performance difference between the editor and release version is very noticeable.

Rohansi 9mo ago
Editor is slower than Mono release builds. You'll need to compare Mono release vs. IL2CPP release to see the actual difference.
- calebh 9mo ago
  I guess it would be good to also see a comparison between IL2CPP and Core CLR by the post author!

Rohansi 9mo ago

The article doesn't cover it but the GC being used by Unity also performs very poorly vs. .NET, and even vs. standalone Mono, because it is using the Boehm GC. Last I heard Unity has no plans to switch IL2CPP to a better GC [1]. It'll be interesting to see how the CoreCLR editor performs. With that big of a speed difference the it might be possible for games to run better in the editor than a standalone Mono/IL2CPP build. [1] https://discussions.unity.com/t/coreclr-and-net-modernization-unite-2024/1519272 https://discussions.unity.com/t/coreclr-and-net-modernizatio...

Rochus 9mo ago
> because it is using the Boehm GC For what reason? Mono has a pretty good precise GC since many years.
- Rohansi 9mo ago
  Yes, SGen should be a lot better, but Unity cannot use it because they hold and pass raw pointers around everywhere. That's fine for Boehm but not possible with SGen. They're working on fixing this already but not sure why they aren't planning a move to a better GC.
  - LeFantome 9mo ago
    Well, if they port to .NET (CoreCLR), that will move them to the MS GC.
    - Rohansi 9mo ago
      Yes, but it also puts them in an awkward situation! They recommend (or even require, for some platforms) using IL2CPP for release builds which will still use Boehm GC and not run as quick as CoreCLR.
      - DoctorOW 9mo ago
        Do they still need IL2CPP if they have AOT? The goal was always to be able to have cross-platform native binaries right?

Inityx 9mo ago

[flagged]

llmslave2 9mo ago
You think? Seems human to me...
- yunnpp 9mo ago
  It's not AI, here's why: (yup, LLM-style pun intended) 1. Uses "I" 2. Look how many times it switches verb tenses here: "One day I was debugging an issue in map generation and it was time-consuming [...]. To make debugging faster, I’ve written a unit test, hoping to cut down on the turn-around time since Unity takes 15+ seconds just to crunch new DLLs [...]. When I ran the test, it finished in 40 seconds."
  - CodeCompost 9mo ago
    It's called a grammar mistake. People make them all the time, that's why editing is a job.
    - yunnpp 9mo ago
      I'm not criticizing their mistakes. I'm saying you can tell the writing is human precisely because of them.

sieep 9mo ago

I recently started learning Godot and learning that they use .NET for the C# runtime is a nice touch. I write a lot of code that targets .NET in my day job, so having to learn the unity way of doing things would be frustrating.

boguscoder 9mo ago

Good article but seems strange that author benchmarked debug builds first, that’s a huge “no-no” in any perf tweaking and it’s clear that authors knows this well

iliketrains 9mo ago
From my experience, performance gains seen in Debug builds in Unity/C#/Mono nearly always translate in gains in Release mode. I know that this is not always true, but in this context that's my experience. Setting up release benchmarks is much more complex and we develop the game in Debug mode, so it is very natural to get the first results there, and if promising, validate them in Release. Also, since our team works in Debug mode, even gains that only speed things up in Debug mode are valuable for us, but I haven't encountered a case where I would see 20%+ perf gain in Debug mode that would not translate to Release mode.
mort96 9mo ago
I agreed with you initially, but is it really as big of a deal in C#? I'm used to compiled languages where "debug build" means "no compiler optimisations", aka every operation done with a variable is a memory load + store, trivial functions aren't inlined so even trivial accessors called in a loop carry function call overhead, etc etc. But this is C#, so the JIT presumably optimises just as much in a debug build as in a release build? So in C++ terms, it's really just benchmarking "-O2" instead of "-O2 -DNDEBUG". This seems fine.

1a527dd5 9mo ago

> In 2018, Unity engineers discussed that they are working on porting the engine to .NET CoreCLR Hard task, no doubt. Unity needs to throw everything at this problem. C# in general has gotten insanely fast by default. It's very much worth taking the time to upgrade/update. Whilst we don't compare in size and api surface, it took us a few months to get off 472 and onto dotnet6. But once we were on dotnet6, moving to the LTS after that was relatively painless; usually a few hours of work.

reactordev 9mo ago

Unity has a unity problem. While it’s easy to get in and make something (it’s got all the bells and whistles) it also suffers from the monolith problem (too many features, old code, tech debt). The asset store is gold but their tech feels less refined. It’s leaps and bounds where it was when it started but it still has this empty feel to it without heavy script modifications. There is the problem. The scripting ending designed around mono doesn’t translate as well to CoreCLR and using the same Behavior interface gets a little more complicated. There are times (even with my own engine) that one must let go of the old and begin a new. Dx7->dx9, dx9->opengl, opengl->vulkan, vulkan->webgpu. EDIT I was just thinking, returning to this a couple of minute later, that if Unity wanted to prove they really care about their Core, they would introduce a complete revamp of the editor like Blender did for 3.X. Give more thought to the level editors and prefab makers. Give different workflow views. Editing / Animation / Scripting / Rendering / Post As it stands now, it’s all just a menu item that spawns a thing in a single view with a 1999 style property window on the side like Visual Studio was ever cool.

DiabloD3 9mo ago
That last step is nonsensical: WebGPU is a shim layer that Vulkan-like layer (in the sense that WebGL is GLES-like) that allows you to use the native GPGPU-era APIs of your OS. On a "proper OS", your WebGPU is 1:1 translating all calls to Vulkan, and doing so pretty cheaply. On Windows, your browser will be doing this depending on GPU vendor: Nvidia continues to have not amazing Vulkan performance, even in cases where the performance should be identical to DX12; AMD does not suffer from this bug. If you care about performance, you will call Vulkan directly and not pay for the overhead. If you care about portability and/or are compiling to a WASM target, you're pretty much restricted to WebGPU and you have to pay that penalty. Side note: Nothing stops Windows drivers or Mesa on Linux from providing a WebGPU impl, thus browsers would not need their own shim impl on such drivers and there would be no inherent translation overhead. They just don't.
- reactordev 9mo ago
  I’m foreshadowing a future where they do. Please don’t kill the dream.

pwdisswordfishy 9mo ago

The author (probably unknowingly) glosses over a lot in these sentences of the "How did we get here" section: > Unity uses the Mono framework to run C# programs and back in 2006 it was one of the only viable multi-platform implementations of .NET. Mono is also open-source, allowing Unity to do some tweaks to better suit game development. [...] An interesting twist happened nearly 10 years later. Not mentioned is that Mono itself of course improved a lot over the years, and even prior to MS's about-face on open source, it was well known that Unity was hindered by sticking with an old and out-of-date Mono, and they were very successful at deflecting the blame for this by throwing the Mono folks under the bus. Any time complaints about game developers' inability to use newer C# features came up, Mono/Xamarin would invariably receive the ire* because Unity couldn't come to an agreement with them about their license and consulting fees. (Mono was open source under LGPL instead of MIT licensed at the time, and Unity had initially bought a commercial license that allowed them exemptions from even the soft copyleft provisions in the LGPL, but the exemption was limited and not, for example, for any and all future versions, too, indefinitely.) Reportedly, they were trying to charge too much (whatever that means) for Unity's attempts to upgrade to the modern versions. It's now 10+ years later, and now not only Mono (after being relicensed under MIT) but .NET CoreCLR are both available for Unity at no cost, but despite this it still took Unity years before they'd upgraded their C# language support and to a slightly more modern runtime. Something else to note: Although, LGPL isn't inherently incompatible with commercial use or even use in closed source software, one sticking point was that some of the platforms Unity wished to be able to deploy have developer/publisher restrictions that are incompatible with the soft copyleft terms in the LGPL that require that users (or in this case game developers) be allowed to relink against other versions of the covered software (including, for example, newer releases). Perversely, it's because Unity sought and obtained exemptions to the LGPL that both end users and game developers were hamstrung and kept from being able to upgrade Mono themselves! (It wouldn't have helped on, say, locked down platforms like Nintendo's for example, but certainly would have been viable on platforms without the first-party restrictions, like PC gaming or Android.) By now, Unity has gone on to pull a lot of other shenanigans with their own pricing that seems to have sufficiently pissed off the game development community, but it should still not be forgotten when they were willing to pass the blame to an open source project over the development/support that the company felt it was entitled to for a price lower than they were told it would cost, and that they themselves were slow to make progress on even when the price of the exemption literally became $0. * you can find threads with these sorts of comments from during this period right here on HN, too, but it was everywhere

Rohansi 9mo ago

[flagged]

luaKmua 9mo ago

In general when game development comes up here I tend not to engage as professional gamedev is so different than what other people tend to deal with that it's hard to even get on the same page, but seeing as how this one is very directly dealing with my expertise I'll chime in. There are few things off with the this post that essentially sound as someone more green when it comes to Unity development (no problem, we all start somewhere). 1. The stated approach of separating the simulation and presentation layers isn't all that uncommon, in fact it was the primary way of achieving performance in the past (though, you usually used C++, not C#). 2. Most games don't ship on the mono backend, but instead on il2cpp (it's hard to gauge how feasible that'd be from this post as it lacks details). 3. In modern Unity, if you want to achieve performance, you'd be better off taking the approach of utilizing the burst compiler and HPC#, especially with what appears to be happening in the in sample here as the job system will help tremendously. 4. Profiling the editor is always a fools errand, it's so much slower than even a debug build for obvious reasons. Long story short, Unity devs are excited for the mentioned update, but it's for accessing modern language features, not particularly for any performance gains. Also, I've seen a lot of mention around GC through this comment section, and professional Unity projects tend to go out of their way to minimize these at runtime, or even sidestep entirely with unmanaged memory and DOTS.

oppo777 9mo ago
[flagged]
iliketrains 9mo ago
Author here, thanks for your perspective. Here some thoughts: > approach of separating the simulation and presentation layers isn't all that uncommon I agree that some level of separation is is not that uncommon, but games usually depend on things from their respective engine, especially on things like datatypes (e.g. Vector3) or math libraries. The reason I mention that our game is unique in this way is that its non-rendering code does not depend on any Unity types or DLLs. And I think that is quite uncommon, especially for a game made in Unity. > Most games don't ship on the mono backend, but instead on il2cpp I think this really depends. If we take absolute numbers, roughly 20% of Unity games on Steam use IL2CPP [1]. Of course many simple games won't be using it so the sample is skewed is we want to measure "how many players play games with IL2CPP tech". But there are still many and higher perf of managed code would certainly have an impact. We don't use IL2CPP because we use many features that are not compatible with it. For example DLC and mods loading at runtime via DLLs, reflection for custom serialization, things like [FieldOffset] for efficient struct packing and for GPU communication, etc. Also, having managed code makes the game "hackabe". Some modders use IL injection to be able to hook to places where our APIs don't allow. This is good and bad, but so far this allowed modders to progress faster than we expected so it's a net positive. > In modern Unity, if you want to achieve performance, you'd be better off taking the approach of utilizing the burst compiler and HPC# Yeah, and I really wish we would not need to do that. Burst and HPC# are messy and add a lot of unnecessary complexity and artificial limitations. The thing is, if Mono and .NET were both equally "slow", then sure, let's do some HPC# tricks to get high performance, but it is not! Modern .NET is fast, but Unity devs cannot take advantage of it, which is frustrating. By the way, the final trace with parallel workers was just C#'s workers threads and thread pool. > Profiling the editor is always a fools errand Maybe, but we (devs) spend 99% of our time in the editor. And perf gains from editor usually translate to the Release build with very similar percentage gains (I know this is generally not true, but in my experience it is). We have done many significant optimizations before and measurements from the editor were always useful indicator. What is not very useful is Unity's profiler, especially with "deep profile" enabled. It adds constant cost per method, highly exaggerating cost of small methods. So we have our own tracing system that does not do this. > I've seen a lot of mention around GC through this comment section, and professional Unity projects tend to go out of their way to minimize these at runtime Yes, minimizing allocations is key, but there are many cases where they are hard to avoid. Things like strings processing for UI generates a lot of garbage every frame. And there are APIs that simply don't have an allocation-free options. CoreCLR would allow to further cut down on allocations and have better APIs available. Just the fact that the current GC is non-moving means that the memory consumption goes up over time due to fragmentation. We have had numerous reports of "memory" leaks where players report that after periodic load/quit-to-menu loops, memory consumption goes up over time. Even if we got fast CoreCLR C# code execution, these issues would prevail, so improved CG would be the next on the list. [1] https://steamdb.info/stats/releases/?tech=SDK.UnityIL2CPP https://steamdb.info/stats/releases/?tech=SDK.UnityIL2CPP

darig 9mo ago

[dead]

LeFantome 9mo ago

It blows my mind that Unity has not been able to migrate to .NET (CoreCLR) after starting back in 2018. I would have estimated a year, or two tops, for that project.

MindSpunk 9mo ago

CoreCLR doesn't help on console platforms because you can't ship the JIT runtime. To my knowledge CoreCLR's AOT solution won't work because of SDK and build requirements for shipping builds on consoles. I believe some consoles require that all shipped native code must have been compiled with the SDK compiler. Even if you fork the CoreCLR AOT system so you can build for the consoles (the code can't be open because of NDAs) you wouldn't be allowed to ship the binary. IL2CPP is the only path forward there. CoreCLR is only viable on PC.

CyanLite2 9mo ago
Simply not true, this info is outdated by a decade. CoreCLR NativeAOT is already shipping real games on Nintendo, PS5, and Xbox. JIT isn't allowed on iPhones either, and this is what NativeAOT solves. Also, .NET is moving WASM support to CoreCLR (rather than mono) in an upcoming version as well.
- MindSpunk 9mo ago
  Do you have examples? As far as I'm aware based on current info there's at least one current console vendor that requires all native code to be generated by their SDK.
  - neonsunset 9mo ago
    Just don't ship to PlayStation and discourage others until Sony changes (is forced to) policy.
    - pjmlp 9mo ago
      Capcom does, and they are quite happy with it.
pjmlp 9mo ago
Yes, it does, Capcom is using it for their Playstation 5 games, like Devil May Cry. "RE:2023 C# 8.0 / .NET Support for Game Code, and the Future" https://www.youtube.com/watch?v=tDUY90yIC7U https://www.youtube.com/watch?v=tDUY90yIC7U As always, it is a matter of having the skill to deliver, instead of GC phobia.

BatteryMountain 9mo ago

My dream would be that I can adb into my phone, install the .Net SDK or .Net Runtime (v 8 or 10) and have my applications run natively on Android. Simple console apps first, then the rest. Google should open their platform up a little bit more. Allow us to enable root access via adb. Let us unleash our pocket computer's full potentials. Would love to have portable low powered servers, running stacks of my choice. They are super efficient already, have large storages, I can already plug in a usb-c hub into my phone to get more storage, LAN network, keyboard/mouse, external mic if needed. Running my phone with wireguard/tailscale + some lightweight containers = awesome! Unity really do need to catch up though. .Net 8/10 is really amazing and FAST. With the new garbage collector changes for .Net 10, game stutter would be nearly gone gone. Unrelated point: I basically stream most of my games with Sunlight + Moonlight from my main rig to my phone with a controller attached, so I can play Diablo 2 remastered, Hades, Grim Dawn and basically any game with Xbox controller support, directly on my phone. Works amazingly well. Phones has high dpi screen + 120hz OLED panel and since all rendering happens on my headless gaming server, at highest settings, the phone's battery doesn't really drain at all, can play for hours. Playing a Mono based game from the play store can drain the battery within 2 hours, and the games are usually so badly built for android, even paid games that have equivalents on steam.

littlecranky67 9mo ago
> My dream would be that I can adb into my phone, install the .Net SDK or .Net Runtime (v 8 or 10) and have my applications run natively on Android My understanding is that you can (almost) do that using MAUI (formerly known as Xamarin). You will not get a .Net SDK or Runtime, but the mono runtime. Since it is bundled in your app, you won't actually notice.
- BatteryMountain 9mo ago
  No, we need one level lower & zero mono. I want the sdk or runtime to be installed in the same way (and executable) the same way on android as on other linux distro's. .Net has ARM builds so it will work fine. This is without any specific framework dependencies (like aspnet, maui, avalonia etc) - just plain .net 8/10. It would actually be nice if android just bundled the runtime to begin with so we don't have to. They can just pin it to latest LTS versions and let it auto update now & then, same way as WebView/Google play services etc.

LarsDu88 9mo ago

Ah I wonder if this could've saved me countless hours of optimizing my VR game Rogue Stargun for the Quest 2, particularly the final battle in the game

NooneAtAll3 9mo ago

my main problem with Unity games is never the speed - it's the outrageous RAM usage

skrebbel 9mo ago

Does anyone on here know why it is that Unity doesn't just run on .NET? The cross-platform benefits of Mono have disappeared a decade ago or something like that. Like, why would Unity invest in hacks like il2cpp rather than just port over to modern .NET? Is there some licensing thing going on?

rincebrain 9mo ago
The article touches on it - assuming it's correct, it's because they did a bunch of proprietary modifying on Mono, so it's not "just" Mono any more, it's Mono and a decade or more of the most exciting layer violating crimes you can imagine. I would assume, if someone Meta scale had an app that had to be built on Unity for whatever reason, we'd see similar blogposts to the ones they did about finding bespoke optimizations for their Android app to be performant with how enormous it became, probably involving either some bespoke alternative to IL2CPP, or writing a bunch of bespoke optimizations onto a bastard descendant of whatever version of Mono Unity originally derives from and so supports...or just paying Unity so much money they get to do whatever they want to the underlying source.
- tyleo 9mo ago
  I’ve heard (but don’t have an inside source) that Meta’s Horizon was built on Unity and then ported to a custom engine implementation.
WorldMaker 9mo ago
Sunk cost fallacy will be a big factor. They already invested a lot of money/time into customizing Mono and hacks like Burst and IL2CPP, so there's momentum to "stay the course" and continue investing in those. Even if some evidence suggests that it is the wrong course.

enbugger 9mo ago

Not to mention the Hot Reload which comes out of the box.

tyleo 9mo ago

I wrote the Circuits programming system for Rec Room, and we took a similar approach: keeping the core logic free of Unity dependencies so it could run and be tested on CoreCLR. The results were similar as well with significantly better performance outside of Unity. There are also secondary benefits. Unity’s API surface is huge, and it’s easy for code to accidentally entangle itself with engine details in ways that confuse or constrain other developers. By isolating the core in a separate DLL, we only expose Unity concepts where they’re actually needed, and we enforce that boundary with tests. That logic constraint ended up being just as valuable as the performance gain

KronisLV 9mo ago

It's cool to see detailed traces and flame graphs be used more often! A lot of different problems could be detected if they were available for pretty much any language, with enough details and tooling to be useful. Heh, I remember also using VisualVM for finding issues with a web app HTTP thread pool and later with the SQL queries being executed (and also the DB pooling solution).

viktorcode 9mo ago

I wonder why the author doesn't use IL2CPP and sticks to Mono. IL2CPP does produce much faster code, making Mono builds obsolete. This should be the very first step you do if you care at all about performance in Unity.

kkukshtel 9mo ago

Wanted to chime in here with some thoughts/clarifications as I'm the Enginnering Manager of the VM team at Unity, aka the team that is leading the charge on .NET Modernization and the CoreCLR transition (and also owns IL2CPP). Also speaking here as myself and obviously not on behalf of the company. First thing is that CoreCLR is _very_ much an active development effort and we're committed to the roadmap we presented at Unite, with at least a CoreCLR-backed Player (aka, what you "Build" when you build your game with Unity) being delivered as a technical preview around the 6.7 release timing. This would basically mean being able to select "CoreCLR" as a scripting backend option (similar to IL2CPP) and see some of the upside and benefit the author mentions here. That said, Unity isn't a pure C# environment. As lots of people know, there is a robust native layer underlying a lot of the managed (C#) code operating a pseudo-ECS design (not literally DOTS/Entites but an engine architecture thing). This means that a lot of the load-bearing code Unity-the-engine is running every frame is notably _not_ C# code, but instead native code that is, in a lot of cases, already very fast. This means that for tight loops of certain systems in the engine, moving to modern .NET isn't going to carry an implict performance increase of those systems. Said differently, CoreCLR isn't a magic performance bullet for Unity. What we like to say though is that "CoreCLR will make C# code faster", so if your game (or general scripting architecture like the author brings up, with lots of "loose" C#) is very C# dependent, you _will_ see a lot of benefit. One thing we starting to investigate is how much performance there is to gain in Unity-the-engine by migrating legacy native C++ code to C# backed by CoreCLR. C# code can be a lot more maintainable and I'd be lying if I said that we really need _every_ managed->native->managed jump we do in the engine, especially with the performance benefit CoreCLR gives us. There are additional things as well like getting intrinsic-backed (or JIT'd) SIMD code for any C# we write with apis like Span<T>, covering for plenty on places in native code where we aren't directly checking for processor arch at runtime or the compiler misses some optimization. This is especially relevant as we also move the editor to CoreCLR, and obviously want it to be as fast as possible, and represents some of the attendant benefits of really focusing on .NET modernization. Regardless, CoreCLR is very much the future of Unity and we're all very excited about it and the progress we're making. The player in 6.7 is the first step and there are lots of other parts (like modern C# lang versions) that will be major boons to development writ large. I (personally, as a game developer) see a lot of awesome things possible downstream of the shift and am (again, selfishly) very excited about what's possible.