Tuesday, September 20, 2011 3:22 AM
As WinRT is COM - is there a marshaling overhead in param / retval mapping?
Can you provide some hard figures, best practices in regards to this?
Tuesday, September 20, 2011 6:49 PMModeratorHi -can you be more specific in your question?
Matt Small - Microsoft Escalation Engineer - Forum Moderator
Tuesday, September 20, 2011 8:27 PM
Based on my minimal testing/research so far, there will be some overhead at ABI boundaries. But for all internal code, there is no overhead since COM does not come into the picture at all (talking about managed apps here). That said if you get back a WinRT interface and then you call into it, each of those calls may be an expensive COM call. But based on what I saw so far, the language projections make this a rare scenario, so you'd typically only be dealing with .NET types.
Note that this is not so for C++. In C++ you have a little more manual control over whether you deal directly with the WinRT types or with C++/STL types. While this has flexibility advantages, you also need to pay attention to when you call into WinRT/COM. Example, Platform::String is a thin wrapper over HSTRING. So it's recommended that people use std:wstring for internal use and only use Platform::String at ABI boundaries.
- Proposed As Answer by Matt SmallMicrosoft Employee, Moderator Wednesday, September 21, 2011 1:25 PM
Friday, September 23, 2011 10:42 AM
Correct me if I am wrong:
- the Win8 XAML controls are WinRT COM components defined in in the Windows.UI.Xaml.Controls namespace
- In a metro app, A .NET C# ViewModel class can function as the DataContext for binding a view composed of this XAML
- This would be marshaling across the ABI boundary from the .NET ViewModel to the COM View
- This is a performance problem
- Edited by JReuben1MVP Friday, September 23, 2011 10:44 AM
Friday, September 23, 2011 12:23 PM
When your .NET V-M changes and data-binding updates the WinRT controls, it is a WinRT-call, but in those scenarios the cost of updating the UI will be more expensive than the COM calls themselves. So I don't think that's anything to worry about.
Friday, September 23, 2011 6:35 PM
Nishant, can you explain to me how updating a XAML view on Win8 (which has no message loop, and uses DirectX 11 for GPU hardware acceleration) would be more expensive than the COM marshaling on the CPU?
I have seen some complex XAML views with many 2 way bindings that have high frequency updates - can you provide a profiled analysis with hard numbers to back up your recommendation not to worry?
Friday, September 23, 2011 7:23 PM
There is a message loop, it's just hidden from you. And Nishant is right, there's a lot more work involved in updating the XAML UI. Even using D3D, there is a kernel mode transition. On top of that you have tesselations of geometries on the CPU along with layout, etc. A COM call, though folks should understand the overhead, is small compared to everything else going on. I do think an benchmark is in order...but if you are updating your UI more than 60 times a second...its a waste.
Saturday, September 24, 2011 1:34 PMThere is some overhead, but it is quite small - in our testing, it is significantly less than a comparable APU using P/Invoke. Because windows runtime metadata is very similar to the CLR's native metadata format, it allows the runtime to be more efficient when copying data to and from the runtime.
- Proposed As Answer by Karel ZikmundMicrosoft Employee, Moderator Sunday, September 25, 2011 3:25 AM
Saturday, September 24, 2011 1:35 PM
While there is in fact a message loop, it isn't particularly relevant to JReuben1's question, he is asking about the overhead of calling windows runtime APIs, not the overhead of marshalling calls from one apartment to another.