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.
