Using Late Bound COM Objects

Using Late Bound COM Objects - Late Binding in .NET: Monitoring Performance of the Various Invocation Methods
(Page 5 of 6 )

We have seen a variety of ways to bind to a COM object at runtime. As I pointed out in the beginning of this article, late binding itself carries some rather severe performance penalties. To avoid impacting performance further, you will want to evaluate the relative speed of these invocation methods for your own COM object. To do this, I suggest maintaining a simple test harness to invoke the target COM object each of the three ways on your version of Visual Studio .NET. This will help you make choices for your current code. The tests should then be re-run when the final .NET bits are released to determine if your invocation strategy needs to change. To help you get started, our .NET project provides a simplistic performance testing harness. These final routines of the project call each of the three invocation examples 5,000 times and report the number of seconds required for each set of 5,000 invocations (as a caveat, this is a simplistic example. The COM methods are only passing small strings, and everything is instantiated locally).

In my testing, the simple COM instantiation, without an RCW, was sometimes marginally faster. If the application timed this "simple" routine before timing the two RCW-related methods, the simple example was generally about 1 second faster. On the other hand, if the simple example was timed last, the performance of all three methods was equivalent. Try these timings on your own late-bound objects as your mileage may vary.

Note that the .NET Framework SDK license prohibits formal benchmarking of the code at this time (a reasonable requirement considering we're working with beta code), so these are not authoritative recommendations in this area. Your mileage will vary from mine, and will undoubtedly also vary between Beta 2, Release Candidate 1, and the final released code.
blog comments powered by Disqus