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.