A small comparison of the performance of the UWP / WinRT API projection language

In my opinion, an unusual situation has developed in the development of UWP / WinRT applications: the company is promoting the use of a native SDK from a managed environment. I was wondering how effective this approach is. And for the answer, I decided to write several applications that solve the same problem, relying on the tools provided by the UWP / WinRT API.
For the results of my little test, welcome to cat.

Formulation of the problem

The operation algorithm of each application included the following steps:

1. The executable environment calls the Main () function (do not be surprised that this function always exists in WinRT / UWP applications)
2. The CoreApplication.Run (...) method is passed an IFrameworkViewSource implementation that returns the IFrameworkView interface in the CreateView () method
3. After several initialization steps, the IFrameworkView.Run () method is called, which activates the main application window, starts dispatcher processing of events, and creates a thread / task for performing calculations

To more accurately measure the necessary time to perform calculations, applications were launched without a debugger. The values ​​of the result and the elapsed time were entered into the fields of the local settings of the “Result” and “Time” applications, respectively.
The sequence of measuring the time required to complete all the calculations was as follows:

1. Variable initialization
2. Start timer / initialize start time variable
3. Multiple Conversion: Input -> SHA256 Hash -> Base64 String -> Input
4. Stop timer / time elapsed
5. Writing values ​​to local settings

To read stored values, applications were launched in debug mode, and data was displayed in the console.

In total, five test application projects were created, three of which used the UWP / WinRT API in their work, and two others relied on their own implementation of SHA256 and Base64.
General list of applications:

• CPP (C ++). The cased implementation of the algorithms was taken from github.com/B-Con/crypto-algorithms .
• CPPCX (C ++ CX). Uses the CryptographicBuffer API provided by UWP / WinRT.
• CPPWRL (C ++). Also uses the CryptographicBuffer API, but calls are made in the manner of COM.
• CS (C #). Implemented from github.com/yuriks/SHA2-Csharp/blob/master/Sha256.cs .
• CSWinRT (C #). Used by the CryptographicBuffer API.

Projects written in C #, in addition to the usual execution, were also tested in compilation mode using .NET Native.

Test results

Testing was carried out in two compilation and execution modes: ARM and x86.
Below are runtime charts (values ​​are in milliseconds).





Such a significant difference surprised me a little. To understand, I decided to profile applications using the UWP / WinRT API.
If you reduce all the screenshots to a table, you can get the following:

It is easy to see the reason for such a big difference: in a project written in pure C ++ using WRL, the code run time from the CryptoWinRT.dll library reaches 90 percent, and in a C # project compiled using .NET Native, this value is only 15 percent . So it turns out that most of the time, projects written in C # work at idle.

Conclusion

Of course, it is clear that the method of using the UWP / WinRT API remote from reality is chosen. Most likely in life such a code will never occur at all. But the fact remains, under a certain set of circumstances, your code can work very slowly only because of the overhead incurred as a result of using the language projection. Maybe the best solution in this case would be an alternative implementation that performs similar tasks, but without using the system API.

The source code for all projects is available at https://github.com/altk/sha256comparison