So you’ve started playing around with Unity and discovered this “Mono” thing. Well, Mono things. MonoDevelop, the Mono Runtime, the Mono compiler. Mono, Mono, Mono. If you’re completely in the dark as to the differences between these elements, well, it’s time to learn.
For those who want the TLDR…
MonoDevelop: An interactive development environment (IDE) for writing C# code (among other .NET languages). In simple terms, it’s a text editor with bells and whistles for developing software. Though you really shouldn’t be using it, seeing as Visual Studio Community Edition exists.
Mono Compiler: Transforms human-readable source code into Common Intermediate Language (CIL), which can be interpreted by the Mono Runtime’s Just-In-Time (JIT) compiler and converted into machine code compatible with the executing platform. Again, something else you shouldn’t be using, given Roslyn exists.
Mono Runtime: An implementation of the Common Language Infrastructure; a virtual machine (VM) that can interpret CIL bytecode into something executable. Sadly, you don’t have a choice here — you have to use the Mono Runtime with Unity, though this could change in the far, far future.
Now with that out of the way, how do these elements related to Unity and why do people complain about them all the time?
One of the biggest points of confusion with Unity is its use of the Mono Runtime. It has been a source of pain for any developer that has used Unity extensively, though when handled properly, its shortcomings can be worked around.
The main reason for this is two-fold: Unity comes with a very old version of the Mono Runtime (2.6.5, roughly equivalent to the .NET 2.0 Common Language Runtime) and an equally ancient version of the Mono C# compiler.
As you might expect, the age of these components means performance isn’t as good as more up-to-date versions and bugs addressed long ago by Mono developers remain in Unity.
It’s important to emphasise that the runtime and compiler are two very different things and understandably, new developers getting into Unity may not realise this is the case.
Let’s tackle the compiler aspect first. It’s been possible to use the most recent versions of both the Mono and Roslyn C# compilers with Unity for a while now. Sure, features specific to the .NET 4.0 CLR aren’t available, but it’s possible to get almost everything else that’s compatible with the 2.0 CLR working just fine.
This includes annihilating the notorious
foreach bug that results in needless allocations. Though it’s technically not a bug — more a side-effect of strictly following the C# specification.
So anyone currently complaining about
foreach and Unity really shouldn’t be. Update the compiler and never worry about it again.
Now, the runtime. This is the larger elephant in the room. The reasons for Unity not updating this component are quite simple:
- 1. Licensing issues with Xamarin
- 2. Compatibility with IL2CPP and Unity in general
- 3. It’s hard
That’s about it, honestly. And the first one isn’t even a problem anymore. If you check out Unity’s fork of the Mono repository on GitHub, you’ll see that since the announcement of Mono going MIT licensed, the company has been hard at work getting a 4.2.0 branch of Mono synced with Unity’s hybrid.
However, those hoping Unity will use Mono’s SGen garbage collector will be disappointed. Going from tweets on the matter by Unity developers, the focus is on allowing the current Boehm GC to perform incremental clean-ups, rather than stop-the-world ones.
Still, it’s a start.