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

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

Formulation of the problem

The algorithm of each application included the following steps:

1. The executable environment calls the Main () function (don't be surprised, this function always exists in WinRT / UWP applications)
2. The CoreApplication.Run (...) method is passed the IFrameworkViewSource implementation, which returns the IFrameworkView interface in the CreateView () method.
3. After a few initialization steps, the IFrameworkView.Run () method is called, which activates the main application window, starts the event handling by the dispatcher and creates a thread / task to perform the calculations.

To more accurately measure the required 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 perform all the calculations was as follows:

1. Variable initialization
2. Timer start / start time variable initialization
3. Multiple conversion: input -> SHA256 hash -> Base64 string -> input
4. Stop timer / elapsed time calculation
5. Write values ​​to local settings

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

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

• CPP (C ++). Sichnye implementations of algorithms were taken from github.com/B-Con/crypto-algorithms .
• CPPCX (C ++ CX). Uses the CryptographicBuffer API provided by UWP / WinRT.
• CPPWRL (C ++). It also uses the CryptographicBuffer API, but calls are made in the COM style.
• CS (C #). Taken implementation from github.com/yuriks/SHA2-Csharp/blob/master/Sha256.cs .
• CSWinRT (C #). API CryptographicBuffer is used.

Projects written in C #, in addition to normal execution, were also tested in compile mode using .NET Native.
')

Test results

Testing was conducted in two modes of compilation and execution: ARM and x86.
Below are the runtime diagrams (values ​​are in milliseconds).





Such a significant difference surprised me a little. To figure it out, I decided to profile applications using the UWP / WinRT API.
If you put all the screenshots in a table then 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 running time of the code 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 in idle.

Conclusion

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

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