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

Unity’s CoreCLR Migration: Progress and Skepticism

• Unity has publicly talked about moving from Mono to CoreCLR since ~2018, with shifting targets (initially 2023, now experimental/technical preview around 2026–27).
• Commenters see “painfully slow” progress and describe the roadmap as constantly slipping, leading to doubts about leadership and priorities.
• Others push back on “lack of skillset” narratives, blaming resource constraints, churn in priorities, and business decisions that reduced funding and drove away senior engineers.

Mono vs .NET Performance and Benchmark Quality

• Some report that single‑threaded Mono vs CoreCLR performance used to be similar; they argue the article’s 3–15× numbers mostly measure “Unity engine overhead + old Mono + libraries” vs “bare .NET console app.”
• One poster who benchmarked Mono’s JIT claims Mono can be quite fast on raw IL, and that much of the slowness comes from Unity’s aging libraries and engine architecture.
• Several people note the article’s benchmarks lack detailed methodology (I/O vs deserialization vs allocation patterns), and that profiling only in the editor is misleading, though the author argues editor gains usually correlate with release builds.

GC, IL2CPP, and Runtime Choices

• Unity’s IL2CPP path and use of Boehm GC (instead of Mono’s newer SGen or .NET’s GC) are widely criticized as a major source of pauses, fragmentation, and high memory usage.
• Unity reportedly can’t just swap GC because the engine passes raw pointers extensively.
• There’s debate whether CoreCLR will matter if most shipping games use IL2CPP anyway; some want direct IL2CPP vs CoreCLR benchmarks.

Unity’s Direction, Tech Debt, and Features

• Many see Unity as a monolith weighed down by legacy code, half‑finished features, constant API breakage, and abandoned “preview” systems.
• Asset Store is viewed as both strength and pathology: Unity leans on third‑party solutions, sometimes buys them and under‑integrates them, and the ecosystem suffers from breakage and poor maintenance economics.
• Several describe Unity as “rudderless,” driven by acquisitions and feature checklists rather than by making games themselves.

Alternatives and Workflows (Godot, Stride, DOTS/Burst)

• Stride is praised for modern .NET support but seen as far less feature‑rich than Unity.
• Godot is the main open‑source competitor; its C# integration and web export are improving but still viewed as behind. Opinions split on using C#, GDScript, or C++ modules.
• Experienced Unity devs note that serious projects often rely on IL2CPP, Burst, jobs, and data‑oriented design, and aggressively minimize allocations; others counter that modern CoreCLR could remove much of the need for Unity‑specific perf tech.
• Some studios isolate game logic into engine‑agnostic .NET libraries to get CoreCLR performance and enforce clean boundaries, then use Unity only for presentation.

Platforms, AOT, and Consoles

• One side claims console certification rules make CoreCLR AOT impractical and leave IL2CPP as the only path; others counter with examples of shipping CoreCLR/NativeAOT on major consoles, arguing that constraints are surmountable with sufficient investment.