Problem fundamentally in a Windows Runtime architecture. Marshalling cost between native and managed code in UWP is terrible. As all XAML UI controls now essentially are native COM classes with winmd metadata on top, every call to a Windows Runtime have a heavy marshalling cost. As application manually render on a Canvas it make many MARSHALLED calls to a Windows Runtime. Also, we have similar performance issues with Windows Runtime file I/O. I experienced a significantly worse file I/O performance on UWP platform. Not surprised when realised WHY every I/O operation are async. Every call to a system Windows Runtime API is terrible from a performance perspective. There was no such problems with Silverlight nor with .NET classic apps. For now we have a Frankenstein monster as an universal application platform. All system APIs are basically COM classes and all API calls from a managed code are marshalled between .NET/COM boundary. And this Frankenstein monster is certainly have no chance to survive on a performance constrained ARM devices. This problem must be addressed in haste! Non trivial app which use a custom logic with many calls to a Windows Runtime native APIs is critically suffering from performance degradation. And strangely, .NET Native compilation does not help much. Native compiled C# code is certainly running faster, but marshalling cost of Windows Runtime calls is NOT eliminated. When it come to many Windows Runtime API calls (and manual markup rendering is a case), native compiled C# app run as slow as not native. There is basically no difference. If UWP platform to be widely adopted this issue MUST be fixed. For now it is utterly a nonsense to use C# in a non trivial app on UWP platform. Period. .NET Native toolchain MUST be improved to dramatically reduce marshalling costs of Windows Runtime calls. I agree with that marshalling between .NET and COM was never good, it always was painful from a performance perspective. But with .NET Native there is opportunity to dramatically reduce marshalling costs. This issue become CRITICAL after all standard APIs are remastered as COM classes with winmd metadata. In classic .NET desktop apps COM interoperability is a seldom used specific scenario. In a UWP app COM interoperability is a fundamental nature of things. Problem must be fixed or UWP platform will never gain adoption - it suffer from a critical and fundamental performance issues for now.
Any ideas? This issue is really critical for a complex non trivial .NET UWP applications and libraries.
Template10 library already have major performance issue with this high .NET/COM interop cost. Excessive execution of one event handler with Windows Runtime calls caused a performance disaster.