Export (0) Print
Expand All

This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

Putting COM Calls to the Test

To deliver consistent adequate application performance, developers, administrators, and network administrators must understand many details about application development and IT infrastructure. The typical response when an application is performing poorly is to ask the DBA to add hardware (CPUs, memory, or disk) or tweak indexes or other database parameters. But you might find the solution to your performance problems in the way you use COM objects.

Many applications today call COM objects to perform certain functions, and applications make these calls in several ways. For example, you can bind to the object early by specifying the object's program ID during the development process or you can bind late by specifying the object's program ID at runtime. Which calling technique you use can have a dramatic effect on performance.

I recently worked with a student who created a small Visual Basic (VB) application to test the various ways of using COM components. You can run COM objects in process in the calling application's memory space or run the objects out of process in their own memory space. You can also use Distributed COM (DCOM) to run remote objects. The COM test used two components-a DLL and an EXE-and executed them 100,000 times for each type of use. The following table shows the results, with time recorded in seconds:

In Process
DLL Early Bound: 0.1602
DLL Late Bound: 1.4258

Out of Process
EXE Early Bound: 26.3164
DCOM EXE Early Bound: 58.2031
EXE Late Bound: 66.2656
DCOM EXE Late Bound: 128.6641

These test results clearly show two things. First, in-process calls are fast. Second, early binding in-process calls are fastest. All other tested techniques add varying levels of overhead.

If your developers create applications that use COM or DCOM, you're going to have to live with a certain level of overhead. With DCOM in particular, you can tune the database all day long, but your applications will only run faster when you change them to use local instead of remote objects.

In our quest for better performance, developers must learn about IT infrastructure considerations, and IT infrastructure managers must understand development considerations. Only such cross-pollination can yield optimum performance for enterprise applications.

Bugs, comments, suggestions | Legal | Privacy | Advertising

Copyright © 2002 Penton Media, Inc. All rights reserved.

Show:
© 2014 Microsoft