Performance Considerations

I l @ ve RuBoard

All of the features I've described in this chapter allow you to publish your .NET components to the wide world of COM, but not without a price. Transitions ”from PInvoke or COM interop ”always imply additional associated overhead, however small. The overhead penalty for PInvoke is roughly 10 native (assembly) instructions per call; for COM interop, it is roughly 30 to 50 instructions per call. For the most part, you can consider the calling overhead to be constant. This should lead you to ask certain questions about how you use functions or COM objects.

More Info

More information on COM interop and performance issues can be found on the MSDN Web site in an article titled "Microsoft .NET /COM Migration and Interoperability." The URL is http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/cominterop.asp.

What it boils down to is this: you should do substantial work whenever you cross the boundary between the unmanaged and managed world. Think of it this way. A simple property on a COM object might have only a four- or five-instruction overhead. If you call that property through COM interop, you've increased the calling overhead to roughly 55 instructions ”a potentially noticeable difference, if you invoke the property frequently. This can lead to horrendous performance degradation in your application.

On the other hand, if there is a method that you can call that not only sets the property but does additional needed work, you can potentially reduce the effect of the interop overhead. The longer the method takes to run, the less noticeable the COM interop overhead will be. I consider frequent calls to lightweight methods to be chatty , while less frequent calls to methods that do a significant amount of work are chunky . In the distributed application model, chunky calls are vastly preferable. Also keep in mind that data marshaling adds additional overhead. The amount of additional overhead will depend greatly on the type and size of the data to be marshaled. Wherever possible, try to pass only blittable types, rather than more complex nonblittable types, because they result in significantly less marshaling overhead.

Memory Considerations

Remember that when you use native methods to create unmanaged data structures, these structures are created outside of the managed environment. In other words, the CLR has no idea that this memory has been allocated and if you don't clean it up yourself, the CLR never will (at least until the application is terminated and all memory is released). You can appreciate that keeping objects and resources lying around until application termination is wasteful at best. At worst, it can seriously affect the runtime behavior of your application. Be a good developer and clean up after yourself.

I l @ ve RuBoard