Coding Sanity

I broke one of the main rules of programming the other day. I'm writing a control which will host a COM control. Now, this COM control has a very chatty interface. So I thought, why not write an ATL shim between my .NET control and this COM control that will handle the chatty aspects. and only pass up the important stuff. So, I duly went along and spent a week and a half implementing this C++ shim.

Now the problem is that while I knew each Interop call would cost me cycles, and I knew that there were quite a few Interop calls, I hadn't profiled the problem. I came to my senses a couple of days ago, and wrote a pure .NET version in just a couple of days. Profiled the two, and what do you know, the performance differential between them is miniscule. Turns out that most of the chattiness is at startup and teardown, and much less during operation.

A typical example of premature optimization. You can't reliably know what's going to be the performance critical sections until you profile the system. I should have written in .NET, profiled it, and if there were bottlenecks, optimized those.

Just as another little performance tip with Interop. The main library I was using was MSHTML. It turns out that an awful lot of my startup time was going in loading this gigantic Interop library: 7.63MB, or almost 3 times the size of mscorlib. That's a lot, and all I needed was a subset. A little scratching around on the Web, a bit of Reflector, and all of a sudden I had the interfaces I wanted in 152KB. This is quite a useful trick when dealing with Interop. The Primary Interop Assembly is not an all or nothing proposition.

When using Reflector to look at interop assemblies, it's worth noting that Reflector puts property get accessors before property sets, so if you're using it as a guide, make sure that you check the IDL for the correct ordering. Filed under: Interop