2

I now understand that WinRT is an API on top of several implementations (Win32 for example) but provided it in an"Oriented Object" way thanks to COM, and the new ECMA 335/CLI metadata. (see How does Windows 8 Runtime (WinRT / Windows Store apps / Windows 10 Universal App) compare to Silverlight and WPF?)

As a .Net developper, I always learned to avoid as much as possible P/Invoke, COM or every "external/interop" calls because of the bad performance. (if we can use a C++/CLI wrapper for native library calls it's always better)

  • Are the performance of the COM WinRT API better as traditional COM ?
  • If so, is it thanks to the ECMA 335 metadata or a new implementation?
  • What do we have "hunder the hood"?
Community
  • 1
  • 1
Mathias Kluba
  • 122
  • 5
  • 1
    @RitchMelton: that is a falsehood. – Sam Axe Aug 21 '12 at 19:34
  • Actually, P/Invoke is not an issue with performance. Any C++/CLI wrapper will use P/Invoke in the end, so the argument there is kind of wonky. COM can have some performance issues, but it depends on the implementation. Anything late bound performs worse than specific interfaces. – Erik Funkenbusch Aug 21 '12 at 19:37
  • Performance considerations always depend on what you want to do. DirectX is based on COM and it is virtually as quick as it can be. Thus the question is not specific enough to gain a single answer rather than a discussion. – Filip Skakun Aug 21 '12 at 20:13

2 Answers2

3

Your problem with performance with COM (or WinRT, which is COM basically) will come down to being exceptionally "chatty" (ie making a lot of calls in a very short time) or with data marshalling.

Any method call that takes a small amount of time will hurt performance if you call it all the time. So I assume that a WinRT call is not as fast as a call from one method to another inside the same .NET assembly (I assume the JIT will optimise it away or optimise it to be insignificant). If the same level of optimisation cannot be made, then you'll notice the method calls - if you overdo it. For example, people used to say virtual method calls in C++ hurt performance, simply because they required a vtable indirection that couldn't be optimised to nothing like normal function calls.

The biggest performance hit though is data, making a call to an external system usually requires that your data gets translated into a format the other system can understand - that is a bigger perf hit than you realise. Even if you do not have to marshal it, you often have to copy the data - so instead of passing 4 bytes of a reference pointer, you have to copy the entire data, or pin it so it can still be accessed from the other system outside of your calling environment. This can hurt perf in a smaller way, but still is not as fast as the direct call.

I'd say in both cases, calling WinRT methods is not going to hurt you so much, there is a layer between .NET and WinRT (similar to the old auto-generated COM wrappers) but is apparently much lighter.

gbjbaanb
  • 51,617
  • 12
  • 104
  • 148
1
  • Are the performance of the COM WinRT API better as traditional COM ?

There's no magic in a WinRT object that makes it execute faster than an equivalent traditional COM object. They are both COM. What will be faster though, is the time to market - WinRT is a lot easier to deal with as a developer.

  • What do we have "hunder the hood"?

You answered to that already by yourself.

Johann Gerell
  • 24,991
  • 10
  • 72
  • 122