Performance

[ecangi]

Hi,

I just learned about the existence of Coral and I'm very interested in using it next to my existing Mono-based integration. Maybe there are other developers like me that have been working on top of Mono for supporting C# scripting interfaces to low-level engine code, so this might be of more general interest. In my project. the C# performance wasn't a main concern so far, but now that things are shaping up and projects are becoming more complex, I'm checkpointing to see where priorities need to go.

With older and more recent performance benchmarks and blog posts indicating that the CoreClr is potentially 3-10x faster than Mono, I am curious if StudioCherno or other developers have some kind of guidance on potential performance speedup, of benchmarks of the timing roundtrip of introspective calls compared to e.g. Mono, or any other things that might arise when using Coral instead of Mono. I haven't checked if Coral is feature complete or robust yet, so do enlighten me on that too.

I realise that comparing these 2 is apples and pears, but any insight would be appreciated! As far as I understood, Mono's largest handicaps are the time spent in parsing types during assembly intake, and the Mono runtime being a lot slower than CoreClr, especially for hotpaths and lots of tiny objects. Yet, the Mono runtime offers detailed introspection API which also avoids doing Marshal roundtrips for any type of query from native into managed running instances, so depending on how those access patterns run, the actual runtime speedup when using Coral and the CoreClr compared to Mono may not be all that fancy. Please correct me if that's wrong.

Kind regards,
.i

[Emily-TTG]

@ecangi
There isn't really a direct comparison to be made, but a few key points [Thanks to @peter1745 for most of this]:

• Mono internal calls go through a few more layers of shenanigans, whereas with CoreCLR you can basically just treat managed calls as if they were normal dynamic calls in terms of performance considerations

• You cannot [without at least a call to obtain a buffer ptr] write to managed runtime memory with CoreCLR, where you can with Mono; so some bulk object operations may not be able to be implemented as efficiently, at least without some restructuring

• Additionally, simply because it's newer, CoreCLR moving forward supports a lot of optimization features in capacities that Mono will not. CoreCLR's PGO in particular can present avenues for massive speedups according to wisdom from upstream anyway

However, the core impetus behind our switch to CoreCLR/Coral was mostly infrastructural and architectural. Mono is much harder to work with, and requires a much more complex build and distribution environment [and doesn't really play nice with application-local runtime distribution]. Its docs are obtuse and a lot more stuff needs to go through bespoke Mono calls instead of the standard C# marshalling APIs.