I am the main developer on an open source app called Radarr (https://github.com/Radarr/Radarr https://github.com/Radarr/Radarr). It focuses on automatically dow

I am the main developer on an open source app called Radarr (https://github.com/Radarr/Radarr https://github.com/Radarr/Radarr). It focuses on automatically downloading movies and managing said movies. While we have used mono only one „one“ platform technically (Unix), I would still like to add my own experience, since we encountered some different behaviour on macOS and Linux. Also I have spent the last week or so tracking down memory leaks for our App :) First of all, tracking down memory leaks with mono is really not fun. The chances are very high, that the memory leak does not occur in the managed parts of either your or other people‘s code, else the garbage collector should have collected that anyways. While you do have an integrated memory profiler, it seems that they like to change them every so often and even the current one isn‘t very compatible. E.g. one user sent me a profiling report, that I could neither open via GUI nor via the commandline. Furthermore, the only GUI option available is Xamarin profiler, which does not run on Linux (more on that later). While it does the job, it likes to crash a lot and eats up a huge chunk of memory, especially if you have a large profiling snapshot. Since I had to deal with unmanaged leaks (as indicated by the managed snapshots I collected), I tried to use valgrind. However, it seems that mono uses SIGSEGV instead of checking for null pointers beforhand and then uses signalhandlers to throw NullPointerExceptions. This would normally not be a problem, but one part of the mono System runtime is very likely to have a NullPointerException. Thus valgrind sees a SIGSEGV and mono‘s signal handler playing around with the stack. It decides that this is not acceptable and instantly termiantes the app. After I patched that out, valgrind seemed to work, except that it didn‘t find any leaks and the memory leak was not even there anymore! So I just started randomly commenting out lines of functions that could potentially be involved and got lucky. I still haven‘t figured out why that line of code leaks memory though. Furthemore, I also found some memory leaks inside mono‘s native HttpWebResponses. We are still trying out figure out another memory leak that occurs and haven‘t had any luck finding out why. It‘s especially hard, since this particular memory leak only occurs on Linux. (If you want to see the full discussion I recommend you look at issues: https://github.com/Radarr/Radarr/issues/1580 https://github.com/Radarr/Radarr/issues/1580 and https://github.com/Radarr/Radarr/issues/3157 https://github.com/Radarr/Radarr/issues/3157). On the other hand, from my experience the performance itself seems almost as good as on Windows, save for the memory leaks. Some big requests to the backend of the app might take 5-10% longer on mono, but that‘s negligble IMO. So, in short, if you don‘t have any issues with performance it‘s good. However, as soon as you do have some issues, you will be faced with a lot of problems. There is no documentation on profiling or what could cause problems, except for a few standard things that‘s more generally .NET related. By pure luck, I found a guid that shows how you can do profiling for your mono app in Instruments, but that didn‘t help either, since the leaks only occur on Linux. Nevertheless, we are planning on moving to .NET Core anyways, so no I would not use mono.