tl;dr - performance stats20-35% faster.
0MB vs. roughly, 0.75GB / 100k messages.
0.005% - A mere 5k vs. roughly 1 million faults/100k messages)
WinApi's primary objective is to provide access to the native layers of the Windows API from the CLR. However, even on first look it should be clear that the
WinApi.Windows namespace infringes on the
WinForms territory, even though its a tiny sub-fraction of the size of WinForms. Over the years WinForms has been well optimized to be decent - It's not the most efficient beast, but for common programs, it probably takes up less than 2-5% percent of your application's time that it doesn't matter on modern hardware - or so is the general line of thought. However, what's one can refute is that it never was the same as say,
ATL/WTL in C++ or direct Win32 programming to be able to handle message loop heavy applications, or high-performance games.
The WinApi.Windows advantage
- The assembly code generated by the JIT is directly comparable to
ATL/WTLor a Win32 application written by hand.
- The message loop is completely GC-allocation free.
- You have complete control over how messages are processed. You can entirely short-circuit, or manually extend connection points into the message loop logic. ...