| Team-Fly | | | .NET and COM Interoperability Handbook, The By Alan Gordon | Table of Contents | | Chapter Seven. Advanced .NET to COM Interop | Performance Considerations Perhaps the biggest problem with COM Interop is that it can be slow. There are approximately 50 instructions that get executed each time you cross the managed to unmanaged code boundary, and that does not include the time spent copying parameters from managed to unmanaged buffers. You should not, therefore, use COM Interop on chatty COM interfaces, that is, interfaces where you will have to make lots of method calls in order to use the interface. COM Interop is most useful for COM interfaces where method calls are not as frequent and where each method performs more functionality. For instance, if an object has four fields that make up its state, having a separate method to set the value in each field is a chatty interface. A single interface that has four parameters and that allows you to set all four fields with a single method call is preferred. If you have a COM object that has a chatty interface and you decide that you want to use it through Interop, you will probably be better off rewriting the object, especially for a time-critical application, or you can create another COM object that wraps the first object and makes the interface less chatty, that is, you call one method on this wrapper and it makes several calls on the underlying object. With this approach you only cross the managed to unmanaged code boundary once, so you do not incur as great a performance penalty. You will want to make sure that, if you use this approach, the wrapper COM object and the original COM object have compatible Apartments so that you avoid COM marshaling. |