Answered by:
What is the COM marshaling overhead in calling the WinRT API from C# ?
Question
Answers
JReuben1,
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.
-Jer
- Edited byjmorrillMVPFriday, September 23, 2011 7:24 PM
- Marked as answer byJReuben1Friday, September 23, 2011 8:18 PM
All replies
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.
http://blog.voidnish.com- Proposed as answer byMatt SmallMicrosoft employee, ModeratorWednesday, September 21, 2011 1:25 PM
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 byJReuben1Friday, September 23, 2011 10:44 AM
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.
http://blog.voidnish.comNishant, 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?
JReuben1,
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.
-Jer
- Edited byjmorrillMVPFriday, September 23, 2011 7:24 PM
- Marked as answer byJReuben1Friday, September 23, 2011 8:18 PM
- There 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 byKarel ZikmundMicrosoft employee, ModeratorSunday, September 25, 2011 3:25 AM
