Binaryworld - Reduce context overhead for COM+ components ... [ VB -> COM-COM+ ]

Instances of configured components, that is, components configured in COM+, get runtime services owing to context objects. When you instantiate a COM+ component, your instance will live in a context object. When you call a method of your instance, the call will go through the context and that is when COM+ interception takes place. The same is true when the method is done. On the 'way back', COM+ can use interception again before the caller regains control.

Thanks to this model, COM+ can use its magic such as automatic transactions and concurrency support. However, as you know, there is no such a thing as a free lunch. In this case, the price to be paid is memory and execution time overhead. The overhead is definitely not negligible and you should try to reduce it when you don't need the benefits it can give you. To see the difference in execution time, you can do a simple experiment. Instantiate a classic COM component (a non-configured COM+ component) a few thousand times and call a dummy method each time. Compare the total execution time with a default-configured VB6-written COM+ component. (It has, for example, "Not Supported" as its transaction support setting.)

You might say: "OK, it's a huge difference, but I never instantiate that many times anyway." That may be true, but it all adds up. Depending on what the bottleneck in your specific application is at the time, you will often see a difference in real applications if you have thought about reducing the context overhead.

Here's a simple way to reduce context overhead. COM+ components written in VB6 will by default use a lot of services when configured in COM+. COM+ components written in Visual Basic .NET (for example) will by default use no services when configured in COM+. In both cases, it's important to make sure that you don't use more services than you really need, because each service has a price. Your contexts will consume more memory and the method calls to the components will take longer.

For example, use Disabled as your transaction setting if you don't need transaction support. This increases your chance of activating an instance together with another instance in one and the same context object.