How fast is fast?

I don't like to use the "optimization" word when talking about software. Coming from a mathematics and engineering background, the word "optimization" usually means the best possible result. Can we use this word to describe the performance of our code? Hardly. I have learned that there is always some way to make your code run a bit faster.

Sometimes the new approach requires a little change to your code, while other times it will require major rewrites making it an important investment. Is it worthwhile? Well, we have to measure the performance improvement to asses how much of an improvement (if at all) we are talking about.

There are three major tools to help you in the performance assessment and tuning of your application:

• Code instrumentation - a set of programming tools that help you measure the timings of specific portions of your code.
  
• The .NET CF Profiling tools - these help you take a bird's eye view on your whole application's performance drivers.
  
• The Query Execution plan - this is a SQL Compact-specific tool that shows you how the Query Analyzer compiles your SQL command and how it plans to execute it. Some of the execution bottlenecks may become apparent and, with some skills you will be able to make your command run faster.
  

Code instrumentation is simplest to use and involves timing your code. The .NET CF helps you with System.Environment.TickCount and System.DateTime.Now to determine the timing when a specific piece of code runs. The first method is more precise and (anywhere from one tenth of a second to half a second) ad reports elapsed time in milliseconds. The second method is less precise and is accurate to the second. Both methods work by retrieving the time measurement of the process start and end and by subtracting both to get an approximate exucution time.

With the .NET CF 3.5, Microsoft introduced a much more precise time measurement intrument, the System.Diagnostics.StopWatch. Although more precise, I generally don't use this timing method because I don't need all the precision. Timing code involves running a fairly large number of trials and averaging out the timing at the end, so individual timing precision is less of an issue. Also, most of the time you are really concerned about shaving 5, 10 or more seconds from a particular piece of code, you won't care about improving it by 10 milliseconds.

I will be looking at these topics in the next few posts about SQL Compact performance.