Editorials

Optimize Procedural Code Through Loop Reduction

Yesterday we considered optimization of database by reducing the number of looping requests are necessary to fulfill a query. Today I am turning the topic back around to procedural code, where we have a lot more direct control.

There are a couple kinds of common loops found in procedural languages. Most of us are quite familiar with a FOR loop used to inspect each item in an array or collection based on its index. This loop implementation is efficient, but requires the loop process to manage the pointer.

The second kind of loop uses a technique called enumeration. The collection has internal pointers for enumeration, and returns the items from the collection in an internal order. This implementation has more overhead by maintaining an internal pointer to the current item, and an internal organization to determine the next item in its collection. The consumer has no knowledge of how the enumeration is implemented. It simply gets a set of objects, one at a time, upon request.

There are other kinds of enumerators external to collections, providing methods for walking through a set of objects. For example, in ADO you can use a TableReader class which enumerates through a table returned from an ADO call. If you want to do you enumeration in a disconnected form, you can return a DataTable to an in memory object, and then enumerate through that DataTable using a DataTableReader class.

Enough on looping tools; the key question is, “How do we optimize our code when working with loops?” No matter what your looping structure is, there is cost associated with iterating through the collection contents. If you application enumerates through a set of objects multiple times, each with a different process, optimization may be achieved in some cases by enumerating once through the set, and performing multiple processes on each item.

I have found some edge cases where a pre-processing loop actually enhances performance. Sometimes your business logic is applied to multiple detail items where a specific sort order simplifies the code. A collection ahead of applying the business logic in whatever sort order the collection was built. In those cases a pre-processing sort loop can be beneficial.

This isn’t something I get all caught up on when I’m writing code. We’re talking about shaving off milliseconds here. This is something you do when you have business rules that run millions of times. Then you’ll get enough return on your effort to make it worth while.

Let me say that again (is that a loop). Just kidding. This should be good food for thought.

Cheers,

Ben