Runtime: Survey: Native AOT

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Looks like a typo - * 9. Which of these tasks are apart of your production debugging workflow? (Please select all that apply) Maybe it should be "a part of"?

I'm so happy to see this issue! 😄🚀

Question: for UWP devs that have worked with the .NET Native toolchain, should we answer the survey just saying we haven't used CoreRT before, or since .NET Native has many similarities (and some shared code too?) with CoreRT, should we just mention this in the notes and then reply the other CoreRT questions just with respect to our experience with .NET Native? 🤔

@Sergio0694 thanks for the UWP question. I agree, I think it makes sense to mention that in the notes and reply to the use corert if you had used the open source version.

Thanks for posting this survey!

I was also confused about how to answer certain questions as a UWP dev who has only used .NET Native. I have a number of opinions about UWP’s .NET Native toolchain but I didn’t really see a place to write them down. Totally fine if that’s outside the scope of this survey but it might be worth clarifying.

I also suspect “because .NET Native is the default for UWP release builds and required in the Store” is probably the most common reason why people use AOT but it’s not one of the pre-populated answers for question 5.

Thanks for including Avalonia in the GUI options :) We've experimented with CoreRT+Avalonia before and the results were gorgeous native GUI apps :D though we havent maintained compat since it's been 2 yrs then...

An often forgotten part of .net is game development, a lot of platforms do not allow a JIT to run, think of Consoles or IOS devices.
It is very important for the future of game development to get .net native AOT as a first-class citizen of the .net ecosystem.
Some game engines rolled their own AOT (for example Unity does with il2cpp) but it is an absolute trainwreck.
So an official solution would be more than welcome. It could be a industry changing event.
Don't forget that the game industry is overtaking the filming industry in both profit and turnover.
Consoles is where the main profit is being made.

The existing options for optimizing published applications work well for most scenarios that .NET targets today.

...

AOT mostly matters in GUI apps. That's where it needs focus. I don't see webapp, services, etc. needing that

I disagree. For the best end user UX, AOT w/ static linking is needed for game engines, serverless microservices, desktop GUI applications, iOS and Android applications, WASM based client side SPAs/libraries and basic CLI tools (~few MBs).

I have wished that I could easily AOT compile my code while trying out all of the above scenarios in C# over the last few years and I feel that .NET is missing out heavily compared to LLVM based languages like Rust.

The reason why the current publishing options appear to "work well' is because .NET has historically not been suitable for the above scenarios and people just implement their own AOT (e.g.: Unity, UWP, Mono) when using C#. Partial AOT solutions such as native image (e.g., ReadyToRun) might "help" in cold start scenarios for monolithic server applications or large desktop client applications but the binary size is still many times larger than what a full AOT runtime would produce.

.NET already does not "work well" for serverless/containerized microservices - these could heavily benefit from AOT compilation, reduced binary size and minimal dependencies.
The current ReadyToRun + Tiered Compilation + IL Linker solution has already hit a limit for the file size which is annoying for self contained deployments, such as the one recommended by AWS Lambda in their blog post.

The real issue is that there's currently too many runtimes/code generators/toolchains/experiments available with their own quirks: IL2CPP/Burst (Unity), Mono's AOT backend (Xamarin/Blazor/Uno), .NET Native/CoreRT (UWP), Mono's LLVM backend, CrossGen/ReadyToRun (.NET Core), etc. and it's simply unacceptable that .NET does not have a standardized AOT compilation toolchain.

If all these teams combined their engineering effort on something common such as CoreRT, Mono LLVM backend or the now-abandoned dotnet/lilic then AOT would have been a much better experience for .NET devs.

AOT w/ static linking is accessible to a large number of developers now with CI/CD for the masses and it is not just an annoyance for a marginal increase in performance anymore.

C# endgame: Native code, native UI, fast and easy interop, native exports and performance oriented APIs (e.g., System.IO.Pipelines, System.Text.Json).

I disagree with the statement saying webapps wouldn't benefit from this. AOT would help greatly with serverless workloads (aka Azure Functions). Not to mention the benefits from startup time for CLI tools.

I have answered the survey, but to be honest I don't get this continuous asking of surveys since .NET Core 1.0 started, without a clear direction where things are going.

.NET Native is what .NET should have been all along, back when Ext-VOS project started, and there is the experience from Singularity and Midori that you guys can certainly relate to, or even get some internal servers with them going on.

Even Java has decided to catch up with its missing AOT capabilities the team isn't asking what workloads we want to have it working.

We hardly use NGEN, because since .NET release its code quality generation was never improved and the deployment workflow is a pain versus other AOT compiled languages.

So if going forward, AOT is dropped again from .NET consider that all the competition in managed languages is now focusing in AOT toolchains, and they also don't ask which workflows we would like to use the compiler.

I want to see .NET continuing to flourish and being the first option regardless of the scenario, and if anything to take over workflows where Microsoft still forces us to use C++ alongside .NET, which other AOT compiled languages don't have issues with.

I have answered the survey, but to be honest I don't get this continuous asking of surveys since .NET Core 1.0 started, without a clear direction where things are going.

I think it's a great thing that MS is trying to listen to the community, rather than just dictating what we want.

@jkotas I noticed that two different links for this survey are spreading, is that okay?
https://www.surveymonkey.com/r/7THQK5K
https://www.surveymonkey.com/r/SQV8JQK

@texasbruce ask the fellow devs that answered similar surveys regarding cross platform GUI, WCF and EF tooling support how much it has helped.

So while it is nice that they ask us, it would be nicer when actions actually happen. Even for cross platform GUI it remains to be seen if MAUI will actually happen or we get Blazor in Web Widgets shoved as solution.

For me the only acceptable AOT solution is when it generates a true native application with no JIT at all in release mode (no side-by-side solution alias ready-to-run) and when it works on all¹ .NET projects developers are working on. This specifically includes Winforms and WPF. In best case it should then also work standalone without any runtime dependencies without bloating itself up from 3mb to 80mb.

¹ For technical reasons there might be cases/apis AOT cannot support. Saying "on all" means not to support all APIs but all project kinds .NET Core supports: dll / winforms / wpf / winui / console / maui / ... Something similar to changing from .NET Framework to .NET Core which allowed most developers to take over their existing applications is what I have in mind.

_I've also written applications in Delphi and it bugs me to see I just compile and then ship my single Delphi executable elsewhere and it just runs. And its just faster. Same applies to a C++ application when compiled in a specific way. And you can still debug both applications and both applications still provide a useful stacktrace/dump when you decide to include the PDB. But for security reasons you can also decide to NOT include it which then also just works fine. It bugs me to ask myself why cannot we have that with C#? When I heard of AOT plans I expected THIS._

I always see issues with reflection mentioned a lot, and I believe that it actually does not matter that much if ASP.net core produces a big executable.

Most of the places where AOT is a hard requirement are things like CLI tools, games and UI applications, they can be picky about which libraries to include and can sidestep some of reflection issues. The priority should be to enable "clean slate" applications.

I always see issues with reflection mentioned a lot, and I believe that it actually does not matter that much if ASP.net core produces a big executable.

With the release of Blazor WebAssembly I think executable size and also execution speed are going to matter very much and it could greatly benefit from AOT. But for whatever reason it wasn't even mentioned specifically in the survey.

Yes, pretty please ! I was considering using Rust or CoreRT in order to keep the memory safety and gain native speeds & have my code be native callable. But it would be fantastic to have AOT in .NET, as it is incredibly rich and powerful and Rust, while fantastic, is not easy to transition to.

@jkotas I noticed that two different links for this survey are spreading, is that okay?

Yes, we use different SurveyMonkey links for different posts. All links point to the same survey. It allows us to see how the distribution of responses varies depending on where people found the survey.

For gamedev we need this, i suspended working on my game engine https://github.com/amerkoleci/alimer_sharp in favour of native engine using c++, i maintain bindings for DirectX ans vulkan as well, performance is needed here

For gamedev we need this, i suspended working on my game engine https://github.com/amerkoleci/alimer_sharp in favour of native engine using c++, i maintain bindings for DirectX ans vulkan as well, performance is needed here

Identical scenario here 😄, except I didn't suspend it . I like AOT both for the better startup times but also (and in my case, more importantly), the opportunity to have more optimised code - I am fine with a 50% increase in build times for a 10% speedup, which obviously isn't really the attitude of a JIT

I am fine with a 50% increase in build times for a 10% speedup, which obviously isn't really the attitude of a JIT

This is actually one of the big secondary reasons I want AOT in .NET instead of switching to a different ecosystem. I am totally spoiled by the speedy compile times of large .NET projects compared to large C++ or Rust projects.

I want JIT for the fast iteration during development, but AOT once I'm shipping something to my customers.

I had use CoreRT create cross platform (and cross platform) Native libraries.

AOT w/ static linking is urgent needed for game engines in iOS and console platform which disable jit, and also want multiple aot compile modes:

1. full aot
2. hybrid aot which support jit + aot or interpreter + aot run mode
   hybrid aot is really important for game industry, it can be game changer

AOT w/ static linking is urgent needed for game engines in iOS and console platform which disable jit, and also want multiple aot compile modes:

1. full aot
2. hybrid aot which support jit + aot or interpreter + aot run mode
   hybrid aot is really important for game industry, it can be game changer

like mono on iOS platform, aot+interpreter run mode.

Full Aot, single exe, independent runtime and clipping unnecessary codes it definitely makes me kreygasm XD

I've been waiting for this question for 10 years. Damn it, I have 5 cool projects that are gathering dust on the hard drive, because if I release them, any child can reverse them, add little changes to GUI and sell them as their own.

I developed Robocraft, Cardlife and Gamecraft with Unity on PC platform and never needed to use IL2CPP, unless required (read Xbox one), not even for the game servers. I personally would see a mix of JIT compilation and a solution like Burst (which does a better job than I can ever do using explicit intrinsics) as more than enough when performance is necessary. However, I understand that AOT is necessary for the platforms that require fully native code and for those platforms where hardware resources are precious. I understand how the .net platform developers can have mixed feelings about AOT, but I don't think it's an option if we want it to see adopted more broadly in game development. To be honest it scares me a bit that Unity has a monopoly on technology like IL2CPP and Burst.

We develop high-performance, high-scalability financial/scientific simulators. Our simulations can run anywhere from a few minutes to many days depending on the complexity of the model the user creates.

Because of the nature of our simulation software, startup times are almost never a concern, as well as software/binary sizes. For that matter, neither is the time it takes to install the product. For example, it would be completely acceptable to us, if compilation were part of installation, even if such a process took a long time.

I would say that about 25% of the code during a run is dynamically created, so a hybrid approach would be preferred; some combination of AOT and JIT compilation. If the dynamic bits had to be interpreted, I think much of the benefits of AOT would be diminished, at least in our use case.

The GC is our number one issue keeping us from achieving higher scalability (e.g. once we get around 44 cores). Having the compiler be able to do more in-depth inter-assembly optimizations, aggressive in-lining, and escape analysis may allow for more short-lived object to be allocated on the stack instead of the heap.

There are many places in our code-base where JIT code quality becomes a bottleneck particularly with register allocations and dealing with many structures. This forces us to write code to manipulate the JIT compiler to do the right thing (a tug-of-war that is fragile, obfuscating, and hard to maintain) or drop to native code (and we lose much of benefit from lack of inlining and overhead from GC/PInvoke transitions).

Sometimes small improvements to code quality can make crazy wins over the course of a model that runs for hours across numerous cores. To us, the JIT has become a bit fragile (even less deterministic) with performance, as our code base changes with development. Our hope would be that an AOT compiler could take much more time in compiling and generating much higher quality code, reducing some of these unnecessary performance fluctuations, and allow us to keep more of our code base in C#.

In general, I would love to see more invested both in JIT and AOT technologies.

cc @AndyAyersMS

AOT w/ static linking is urgent needed for game engines in iOS and console platform which disable jit,

I totally agree here. As we are in need of a solution for this problem (C# code running on game consoles for a non Unity project) we are using a Mono-AOT based tool chain. But it has some serious limitations and doesn't perform that well. 

Therefore we are looking into getting CoreRT running on 3 poplar game consoles (XBox One; PlayStation 4 and Nintendo Switch). An initial prof of concept show that it actually works (still with some limitations) but already with an significant run time performances improvement compared to the Mono based solution.

But with the NDA situation around game consoles official support for this use cause is properly even more far fetched than getting official native AOT in the first place.

To us, the JIT has become a bit fragile (even less deterministic) with performance, as our code base changes with development.

@jpapp05 I would love to hear more about your app, and the above issue specifically, as it's one of my key concerns. Feel free to contact me offline (via email in profile) if that helps.

Hi @AndyAyersMS, that would be great. I'll contact you offline as I can talk a bit more freely but I'm happy to post back any summary from our discussions for the benefit of others.

Don't know if this is even a problem but just to mention it here.
An important feature for us would be the ability to dynamically load und unload native assemblies at runtime.

@movedoa see the NativeLibrary APIs https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary?view=netcore-3.1

My biggest problem is that usually .NET can be easily decompiled, except with UWP Native, at least as far as I tested (I hope to be right). Not in a "normal" company mindset, someone will put a lot of IP in a project which can be easily decompiled.
Linux is cool ok, but all desktop applications are for Windows in the enterprise world.

Maybe to make the life easier, put a checkbox which says:
NATIVE COMPILATION (WORKS FOR WINDOWS 10 DESKTOP ONLY!)
Man, do that and I don't care about AOT anymore. If it works for ASP.NET Core, cool! If not, I really don't care.

By the way, thanks for creating the issue asking and making the survey, you did a great job because you are asking the opinion from people who uses the technology in their jobs. I think (in fact I'm sure) you still miss tons of desktop developers opinions who usually don't get involved into this things on Github. Not everyone remembers (or knows) that .NET code can be easily decompiled and I'm sure their bosses would go nuts if they knew :grin:.

Not everyone remembers (or knows) that .NET code can be easily decompiled

Shhh... The fact that Rider does this for you automatically is amazing when I am trying to figure out how something works behind the scenes in Unity or 3rd party packages. Not nearly as important now, though, with a lot of the code being open-sourced in the first place, but you get what I mean.

@jcbeppler You are wrong, that is a common misunderstanding of bytecode vs native, it is just a matter of having the right tools.

https://www.hex-rays.com/products/decompiler/compare/compare_vs_disassembly/

Hex-Rays is just a possible solution, there are others to choose from.

@MostHated Yeah, I got it. In fact it's so simple to decompile a software in .NET that it is like is open source and many companies don't want their software being open source. "There ain't no such thing as a free lunch" 😄

@pjmlp I know the difference between decompile vs disassembly. I cannot do anything against disassemblying my software but native compilation can make the software much more secure because the person cannot do a very simple decompilation. A disassembled software will definitely look weird and the disassembled code may not even run correctly.

@jcbeppler You are wrong, that is a common misunderstanding of bytecode vs native, it is just a matter of having the right tools.

Currently a .NET program decompiled reveal the whole source code. This even includes all method names and variable names. This is cool for debugging and allows us to have a "readable" stacktrace when an exception occurs. However its a huge security flaw and a reason why there is a huge market for .NET obfuscators.

A native application can be disassembled. But it does not goes down to reveal its full C++/Delphi etc. source code (there are some tools which tries to rebuild this source code but the results are horrible). What you get is assembler code and control flow charts at most. If you are lucky and it ships with symbol file you also get the function names but in release mode this symbol file is usually not included, again for security purpose.

We can lose ourselves into details talking about how native code is a real protection. In my opinion its not a protection in terms of cracking (although thanks to full full method / variable names and full C# source generation a license check can be removed without requiring any special knowledge) or debugging, but a protection against stealers. Tools like dnSpy can even export the .NET application into a full VS project by a SINGLE CLICK. There is no such tool that works the same way for native code. So for commercial applications it would be a huge win to generate native code, besides of the fact that they no longer have to pay thousands of dollars a year for something that just renames all of the methods and variables in the final application.

I'm curious about the result of this survey. Are there any plans to make them public on how people voted?

@Symbai It is not a protection against anything, as any Android developer that has tried to use the NDK as means to protect their IP will tell you. The applications that you briefly mention, can do the same with single click, and even though they usually assume C or C++ code as original source code, they are good enough to steal your algorithms.

I want AOT, for scenarios where .NET will lose long term against Rust, Go, Swift, C++, Java (GraalVM), desktop, console, and mobile/IoT applications where startup time is really important, there are high constraints on memory usage and speed loss due to JIT on Assembly load is not tolerable, just like on some ASP.NET scenarios AOT code might be relevant when one is scaling their 100 K8S pods instances.

On the other side, I also find relevant to keep the JIT capabilities, and improve them as well, on scenarios where JIT is the way to go.

There are plenty of languages that offer both compilation models, letting their users to pick and chose depending on the situation, so basically lets keep JIT around, and improve the AOT story into .NET Native direction, while forgetting about the timid attempt named NGEN.

@Symbai It is not a protection against anything, as any Android developer that has tried to use the NDK as means to protect their IP will tell you. The applications that you briefly mention, can do the same with single click, and even though they usually assume C or C++ code as original source code, they are good enough to steal your algorithms.

Stealing an algorithm I can live with, but not what .NET allow today (e.g. WPF), where a person have your complete application beautifully and easily ready to run as a VS project. I think UWP with Native compilation does a good job, if someone wants to disassemble it, ok, good luck! I will always use Native compilation, no matter what. Android world I can't talk about, tried AOT with Xamarin Forms one time and it really didn't work as I expected.

I think UWP with Native compilation does a good job, if someone wants to disassemble it, ok, good luck! I will always use Native compilation, no matter what. Android world I can't talk about, tried AOT with Xamarin Forms one time and it really didn't work as I expected.

Spoiler - the people that are trying to get at your source are probably trying to improve/extend/integrate with you, not rip you off. If they're trying to rip you off, then your metrics are really silly.

If I write a book, then get someone to translate it into Japanese before I publish it - I might think I'm really clever, because I don't understand Japanese, and neither do any of my friends. The reality is though, there's entire countries out there who can read that book - and I'm doing nothing more than fooling myself if I pretend otherwise.

I say this as a developer who had no experience with disassembled native binaries, and decided to reverse engineer the encryption and data formats on Star Citizen.

It took me, someone with zero prior experience, two weeks to go from nothing, to having a program that can not only decrypt their encrypted data files, but also convert their proprietary data formats into XML/JSON.

After those 2 weeks - I might not have your complete application ready to run as a VS project - but I also realize that I don't need to. It's far simpler to just inject my own code into the existing application, and not have to deal with all their code.

to having a program that can not only decrypt their encrypted data files

Encryption is something completely different. Decompiling a VIDEO GAME to create mods is something completely different. Most game developers don't mind if their fans create mods, it rather shows their passion and love for the game. And perhaps the "encryption" wasn't an encryption at all but files were just packed for smaller size? For not having to store thousands of single files on disk. Performance could have been a reason too... reading many small files from disk is slower than reading one huge file. And after 2 weeks you were able to unpack packed images. You were able to change text within some data files. This is great but not the reason why people like me want to get rid of JIT.

The problem we have right now is that JIT code can fully decompiled to complete source code, Java has the same issue as well as any other JIT language. Native code can be disassembled (this will turn machine code into assembly code), native applications can be cracked with enough afford, all of this is true but native code cannot be compiled to complete source code. Have you ever seen a tool like dnSpy for C++ code? Delphi code? I haven't. Its because it is not possible to obtain variable and methods names, they simple don't exist anymore when compiled correctly. It is not possible to turn disassembly into C++ and generate a fully working project you can compile. This must sounds like something not so important for you, but its a huge thing for commercial applications. We just want to get rid of the fact that .NET application is an open book everyone with absolutely zero knowledge can read from. When we put thousands of dollars into research, we don't want everyone to look at it and copy it within a couple of seconds. We want to get rid of paying thousands of dollars for an obfuscator that only purpose is to rename all variables and methods names, so people can no longer open the application and search for "license" to immediately get to it. Its not only (but mostly) the costs of the obfuscator but also that obfuscators create additional problems. I ran into this myself quite often especially with the frequency of .NET Core releases. We had to wait several weeks only for a patch that makes the obfuscator work with latest .NET Core version.

And while you face all of these problems as a developer you also have to explain them to your business manager. At some point he might ask you whether its not better to just choose a different programming language then.

With C++ and Delphi you simply don't have this problem. I know that this is not a problem for everyone. Open source developers will find the JIT more interesting and useful. Its hard to explain to them why someone wants his source code to be a closed book, when they believe open books are just better. So ideally, we don't have to explain each other our completely different views and AOT will be just a switch that you can turn on in release mode if you want. And if you dont want, go ahead with JIT.

I'm really thankful of the .NET team letting us choose "protection" as a reason why we want AOT ❤. It shows that they are aware of the needs some people have. And if the polls reveals that man votes for it, we might finally have a chance AOT implementation will take care about this in the same way as a C++ compiler. FYI: I put it in quotes to avoid further discussion about how much protection AOT actually is, the point of views are extremely wide on this one, as we might have already noticed.

Security is not all or nothing. Removing IL does not prevent a determined attacker from reversing an application. But it creates hurdles that are relevant in a practical sense. It is defense in depth. This is why IL obfuscation products can be rational to use.

A friend of mine has cracked .NET products by decompiling IL to C# and making rather trivial modifications. He is not capable of cracking native applications. It is much harder. He also had to give up in the presence of IL obfuscators because the decompiler tool crashed on those binaries. Again, those products were protected in a practical sense. It worked.

@Symbai

Have you ever seen a tool like dnSpy for C++ code? Delphi code?

Hex-Rays does a good job for C, and it has macros to help the decision process.

Having C source it is a kids play to convert it to C++ or Delphi.

Plus now we have AI to help those not skillful enough.

Neural Reverse Engineering of Stripped Binaries

Hex-Rays does a good job for C, and it has macros to help the decision process.

Do you work for Hex-Rays or for a company which sells obfuscation software? It appears that.

Anyway, even if you convert it to C, the code will be far far away from a good C# architecture. Even if you get pieces of the code, you will have to put a good amount of effort on it to change, improve, etc....
If for you the native compilation is irrelevant, ok. But for many people it is relevant.

BTW: You look very interested in keeping with JIT compilation and also you appear to have a lot of experience in disassembling software. I am wondering why and where you had to use that?!

Regardless of how any of you feel about the ease of decompilation of IL vs machine code, it doesn't change the fact that it is a real requirement at real businesses. (And we could argue about how valid or invalid that requirement might be until the cows come home.)

My previous employer explicitly forbade shipping .NET or JVM tools externally for this reason. Right before I left one team convinced the higher ups to let them ship a tool with heavy obfuscation applied, but otherwise we were writing external tools in C++ to satisfy corporate policy.

This discussion has gone way off the rails. If you all wanna have a flamewar about whether AOT is relevant for IP protection, please do it somewhere else.

Hex-Rays does a good job for C, and it has macros to help the decision process.

Do you work for Hex-Rays or for a company which sells obfuscation software? It appears that.

Anyway, even if you convert it to C, the code will be far far away from a good C# architecture. Even if you get pieces of the code, you will have to put a good amount of effort on it to change, improve, etc....
If for you the native compilation is irrelevant, ok. But for many people it is relevant.

BTW: You look very interested in keeping with JIT compilation and also you appear to have a lot of experience in disassembling software. I am wondering why and where you had to use that?!

On the contrary, I possess the skills to reverse engineer native code to source code that can be further used by third parties, so I am fully aware that compiling to native code is only an hurdle for script kiddies, which seems to be the missing understanding here.

EDIT: Also stoping my comments. Just wanted to reply to the personal attack.

Cloud Native and WPF Must be AOT.
Windows client no runtime ! no JIT

The results of the survey have been posted - https://github.com/dotnet/runtime/issues/41522. We are now in the process of following up with people that provided their contact information and have some additional follow-up questions.

AOT w/ static linking is urgent needed for game engines in iOS and console platform which disable jit,

I totally agree here. As we are in need of a solution for this problem (C# code running on game consoles for a non Unity project) we are using a Mono-AOT based tool chain. But it has some serious limitations and doesn't perform that well. 

Therefore we are looking into getting CoreRT running on 3 poplar game consoles (XBox One; PlayStation 4 and Nintendo Switch). An initial prof of concept show that it actually works (still with some limitations) but already with an significant run time performances improvement compared to the Mono based solution.

But with the NDA situation around game consoles official support for this use cause is properly even more far fetched than getting official native AOT in the first place.

@RalfKornmannEnvision Are you using the Xamarin Xbox One/PS4 Mono ports with LLVM codegen?

@RalfKornmannEnvision Are you using the Xamarin Xbox One/PS4 Mono ports with LLVM codegen?

@lateralusX As the integration was done by someone else I don't know any detail. But as far as I know they used the mono ports that are provided for the XBox One/PS4 and made a simple port for the Switch. themself.

@RalfKornmannEnvision Would be great to get in contact and discuss the experience related to this. The LLVM codegen has (depending on project) very positive performance effects on the generated code so if that was not used (needs to be enabled) there is normally a lot to gain by just enabling that. Are you on the DotNetEvolution discord server, if so maybe we could have an offline discussion there related to this?

@lateralusX I am pretty sure the team members who worked on this have enabled the LLVM codegen and tried other things. Their last statement before moving on to another project was that this is the best they could do.

As part of my investigation I build a benchmark with the core component using Xamarin Android and run it on a Tegra X1 based device to see if we lost performances because of an issue with the our custom Switch port of Mono. Unfortunately the performance of the Xamarin project was not that different of what we have seen on the Switch. 

I am sorry I am not on this discord server and to be honest their is not that much I know about the current MONO integration anyway. From my point of view it's a dead end anyway for this project. The current CoreRT prototype (while having even less official support) is already far superior when it comes to performances and usability. 

@RalfKornmannEnvision OK, thanks for your information and feedback, all very valuable.