For many years a major focus of Mono has been to be compatible-enough with .NET and to support the popular features that developers use.
We have always believed that it is better to be slow and correct than to be fast and wrong.
That said, over the years we have embarked on some multi-year projects to address some of the major performance bottlenecks: from implementing a precise GC and fine tuning it for a number of different workloads to having implemented now four versions of the code generator as well as the LLVM backend for additional speed and things like Mono.SIMD.
But these optimizations have been mostly reactive: we wait for someone to identify or spot a problem, and then we start working on a solution.
We are now taking a proactive approach.
A few months ago, Mark Probst started the new Mono performance team. The goal of the team is to improve the performance of the Mono runtime and treat performance improvements as a feature that is continously being developed, fine-tuned and monitored.
The team is working both on ways to track performance of Mono over time, implemented support for getting better insights into what happens inside the runtime and has implemented several optimizations that have been landing into Mono for the last few months.
We are actively hiring for developers to join the Mono performance team (ideally in San Francisco, where Mark is based).
Most recently, the team added a new and sophisticated new stack for performance counters which allows us to monitor what is happening on the runtime, and we are now able to export to our profiler (a joint effort between our performance team and our feature team and implemented by Ludovic). We also unified both the runtime and user-defined performance counters and will soon be sharing a new profiler UI.