ASP Tips: Tip 6: Encapsulate Code and Working on Resources

Encapsulate Code in COM Objects

If you have a lot of VBScript or JScript, you can often improve performance by moving the code to a compiled COM object. Compiled code typically runs faster than interpreted code. Compiled COM objects can access other COM objects through "early binding," a more efficient means of invoking COM object methods than the "late binding" employed by script.

There are advantages (beyond performance) to encapsulating code in COM objects:

• COM objects are good for separating presentation logic from business logic.
• COM objects enable code reuse.
• Many developers find code written in VB, C++, or Visual J++ easier to debug than ASP.

COM objects have disadvantages, including initial development time and the need for different programming skills. Be warned that encapsulating small amounts of ASP may cause performance penalties, rather than gains. Typically, this happens when a small amount of ASP code is wrapped into a COM object. In this case, the overhead of creating and invoking the COM object outweighs the benefit of the compiled code. It is a matter of trial and error to determine what combination of ASP script and COM object code produces the best performance. Note that Microsoft has vastly improved script and ADO performance in Windows 2000/IIS 5.0 over Windows NT® 4.0/IIS 4.0. Thus, the performance advantage enjoyed by compiled code over ASP code has decreased with the introduction of IIS 5.0.

For great discussions about the benefits and pitfalls of using COM objects in ASP, see ASP Component Guidelines and Programming Distributed Applications with COM and Microsoft Visual Basic 6.0. If you do deploy COM components, it is particularly important that you stress test them. In fact, all ASP applications should be stress tested as a matter of course.

Acquire Resources Late, Release Early

Here's a short tip for you. In general, it's best to acquire resources late and release them early. This goes for COM objects as well as file handles and other resources.

ADO Connections and recordsets are the prime candidates for this optimization. When you are done using a recordset, say after painting a table with its data, release it immediately, rather than waiting until the end of the page. Setting your VBScript variable to Nothing is a best practice. Don't let the recordset simply fall out of scope. Also, release any related Command or Connection objects. (Don't forget to call Close() on recordsets or Connections before setting them = Nothing.) This shortens the time span in which the database must juggle resources for you, and releases the database connection to the connection pool as quickly as possible.