Doing some testing, I needed an array of 100 random floating point numbers that sum to 1.0. That is, given an array a, (a[0] + a[1] + a[2] ... + . . . → Read More: A couple of LINQ quickies]]> I’ve recently had occasion to write LINQ versions of two functions I’d written some time back. It proved instructive.

Random numbers that sum to N

Doing some testing, I needed an array of 100 random floating point numbers that sum to 1.0. That is, given an array a, (a[0] + a[1] + a[2] ... + a[99]) = 1. The easiest way I know of to do that is to generate an array of 100 random values, sum them, and then divide each number by the sum.

    const int ArraySize = 100;
    Random rnd = new Random();
    double[] a = new double[ArraySize];
    double sum = 0;
    // generate the values
    for (int i = 0; i < a.Length; ++i)
    {
        a[i] = rnd.NextDouble();
        sum += a[i];
    }

    // now divide each item by the sum
    for (int i = 0; i < a.Length; ++i)
    {
        a[i] /= sum;
    }

The math behind this is pretty simple. What you end up with is (a[0]/sum + a[1]/sum + a[2]/sum ... + a[99]/sum), which works out to sum/sum, which is 1.

Somebody asked me for a LINQ version.

    var temp = (from d in Enumerable.Range(0, ArraySize)
                select rnd.NextDouble()).ToArray();
    var sum = temp.Sum();
    var a = temp.Select(d => d/sum).ToArray();

An obvious extension to this is generating an array of N values that sum to some arbitrary value. The first part of the algorithm is the same: generate N numbers, and sum them. Then, rather than dividing each number by the sum, divide by (sum/desired_value). Or, you can multiply by (desired_value/sum). So the final LINQ expression becomes:

    var a = temp.Select(d => d*(desiredValue/sum)).ToArray();

And don’t worry about the division in the inner loop there. The compiler (either the C# compiler, or the JIT compiler) will move it out of the loop.

Finding palindromes

At a previous job, one part of the interview process for entry-level programmers was having them solve some simple programming puzzles on the white board. I called it The White Board Inquisition. A common exercise was to write a function that determines if an input string is a palindrome. We’d keep it simple and have them look for an exact match. So “amanaplanacanalpanama” would be a palindrome, but “A man, a plan, a canal, Panama!” would not be. Stripping out the non-alphabetic characters and doing case-insensitive matching is a simple refinement, but we wanted to see how the candidate approached the primary problem.

The simplest way, of course, is to reverse the string and do a comparison, but we wouldn’t allow them to call a reverse method. If they wanted to reverse the string, they’d have to do it themselves. Many did. Another common approach is to push the characters onto a stack and then pop them, comparing the popped values with the string characters, in order.

Few candidates tripped to the in-place method of comparing the characters starting from the outside and moving in, like this.

    private bool IsPalindrome(string input)
    {
        int i = 0;
        int j = input.Length - 1;
        while (i < j)
        {
            if (input[i++] != input[j--])
                return false;
        }
        return true;
    }

Somebody recently asked me for a LINQ version of a palindrome finder. The obvious solution is to employ the Reverse extension method and then compare the sequences. But it’s easy enough to duplicate the above algorithm.

    private bool IsPalindrome(string input)
    {
        return
            Enumerable.Range(0, input.Length / 2)
                        .Select(i => input[i] == input[input.Length - i - 1])
                        .All(b => b);
    }

A common misconception is that the LINQ code will do those three operations in sequence: generate a list of indexes, then generate a list of results, and then compare the results. That most definitely is not how the generated code works. If you enable runtime library source stepping, you’ll see that the sequence of operations follows the looping construct very closely. The LINQ solution is slower, of course, because it’s working with iterators and such, but it isn’t stupid.

The more I work with LINQ, the more impressed I am by what I can do with it. It’s not always the fastest executing solution, but for most of what I do that doesn’t matter. I find that the expressiveness leads to much shorter, more easily understood, and more reliable code than writing large looping constructs. I imagine that interviewers these days expect candidates to demonstrate a thorough understanding of LINQ. I know that I certainly would.

On the north and south sides of the intersection there are three lanes: a left turn lane, a through lane, and a right turn lane. On the . . . → Read More: Confusing traffic signal]]> The two intersections near my office have traffic lights that are unlike any others I’ve seen, and I fear that they are confusing to drivers and therefore dangerous.

On the north and south sides of the intersection there are three lanes: a left turn lane, a through lane, and a right turn lane. On the east and west sides, there are four lanes (two through lanes). All four sides of the intersection have the normal red/yellow/green through lights and a left turn light.

A traditional traffic light is green, turns yellow for a short period, and then turns red. They have been this way for decades–certainly for the 40+ years I’ve been aware of the way that traffic lights work. Left turn lights work much the same way. The left turn arrow might work on a different schedule than the through lights, but it traditionally follows the green to yellow to red pattern. Or, it might have only green and off, meaning that you have to yield to oncoming traffic when the light is off, but the oncoming traffic has a red light when the left turn light is green.

The left turn lights at this intersection are different. And confusing. They blink yellow to mean, “You may turn after yielding to oncoming traffic.” After the blinking yellow period, they turn green. So drivers have to know that solid yellow means “red is soon to come,” but blinking yellow means, “green is soon to come.”

It doesn’t help, of course, that years of experience have taught drivers that in practice a yellow left turn signal means, “Hurry up through the intersection before the light turns red.”

Every day I see drivers not fully understanding what that blinking yellow means. Some, when they see the blinking yellow, dash through the intersection heedless of oncoming traffic. I can only conclude that they don’t understand that the rules have changed and a light might start blinking yellow. Other drivers see the blinking yellow and hesitate when it’s clear that there is no oncoming traffic and they’re fully within their rights to proceed.

I realize that blinking yellow means “proceed with caution.” But traditionally that’s done with all of the lanes at an intersection (going the same way, of course). But drivers aren’t accustomed to seeing blinking yellow on one light, and solid red or green on the other lights. And they’re certainly not prepared for a blinking yellow light to suddenly go green.

I’ll grant that I’ve only seen two crashes (after the fact–I wasn’t present for the actual impact) at these intersections in the three months I’ve been here. But I’ve seen too many close calls to believe that this unorthodox use of the signal lights is a good idea. I can only hope that those in charge of the traffic lights will see this dangerous situation for what it is and reprogram the lights back to something more reasonable.

The leading slash is there because '+' is . . . → Read More: Regular expressions, optimization, and practicality]]> Suppose you wanted a function that would replace multiple instances of a character with a single instance. So the string “+++This+is+++++a++test++” would become “+This+is+a+test+”. The easiest way to do it in C# is to employ regular expressions.

    string testo = "+++This+is+++++a++test++";
    string result = Regex.Replace(testo, @"\++", "+");

The leading slash is there because '+' is a special character in regular expressions. The slash “escapes” the character so that it will be treated as a literal.

By the way, you can’t do this reliably with String.Replace. If you wrote:

    string result = testo.Replace("++", "+");

You would end up with “++This+is+++a+test+”. String.Replace makes a replacement and moves on, so it will miss when the replacement string plus the following characters is equal to the search string.

Curious, I thought I’d write my own function to remove duplicate characters and see how it fares against the regular expression. The result is this RemoveDupes method.

    public static string RemoveDupes(string text, char dupeChar)
    {
        if (string.IsNullOrEmpty(text))
        {
            return text;
        }

        var result = new StringBuilder(text.Length);
        bool dupe = false;
        for (int x = 0; x < text.Length; ++x)
        {
            char c = text[x];
            if (c == dupeChar)
            {
                if (!dupe)
                {
                    result.Append(c);
                    dupe = true;
                }
            }
            else
            {
                result.Append(c);
                dupe = false;
            }
        }
        return result.ToString();
    }

That's the most straightforward way I could think of to write it, so I wouldn't be surprised if there are some optimizations that would make it faster.

I created the regular expression like this:

    var re = new Regex(@"\++", RegexOptions.Compiled);

And in the timed loop, called it with:

    result = re.Replace(testString, "+");

That should make the regular expression as fast as it can be.

Performance testing was a little bit surprising. The simple RemoveDupes method was 5 to 8 times as fast as the regular expression version, depending on the length of the strings and the percentage of repeated '+' characters in the string.

That the custom code was faster didn't particularly surprise me; I've proven many times that a custom parser can outperform regular expressions. Two or three times as fast is what I expected. Up to eight times as fast came as a surprise.

One million iterations with a string 100 bytes long took the regular expression version 4,767 milliseconds, or 0.004768 ms per call. The same string run through the RemoveDupes method took 793 ms, or 0.000793 ms per call. The custom method is six times as fast, but the absolute difference for those million iterations is only four seconds.

Granted, the absolute differences get larger as the number of iterations or the length of the string increases. The timings (and the differences) increase linearly. If it takes RemoveDupes some N seconds to complete, it will take the regular expression approximately 6*N seconds.

But does it really matter? Most likely not. In most cases, sanitizing the input data takes up a very small percentage of the total CPU time. Optimizing it just doesn't yield meaningful performance gains. Unless removing duplicated characters from strings is the most time consuming part of the program, this huge boost in performance would mean nothing.

Would you really notice a forty second difference in the running time of a program that takes an hour?

The other practical matter has to do with time to implement. The regular expression code already works. It took some (small) amount of time to write and test my RemoveDupes method, and the result is a very narrowly-targeted solution: it can remove duplicated characters from a string. Even the seemingly simple modification of letting it de-dupe 2-character strings would be a much more involved job, especially when you take into account the weird edge cases inherent in Unicode. Writing and debugging that would be difficult.

I think I'll stick with regular expressions for this kind of job, even though they're slower than the custom parser. Unless I really need the speed.

The assertion is that accessing jaggedArray will be faster.

I’ve rarely seen any kind of benchmark to back . . . → Read More: Are jagged arrays faster than rectangular arrays?]]> In reading about C# performance optimization, I often encounter the conventional wisdom that jagged arrays are faster than rectangular arrays. That is, given these two arrays,

    byte[,] rectArray = new byte[NumRows, NumCols];
    byte[][] jaggedArray = new byte[NumRows][];

The assertion is that accessing jaggedArray will be faster.

I’ve rarely seen any kind of benchmark to back up that assertion, and of the benchmarks I have seen many are fundamentally flawed. I’m exploring a project that will make heavy use of arrays, so I thought I’d look into the relative performance of both array types.

Before I do that, though, I should mention that often you don’t have a choice of what type of array to use. If your job is to process a two-dimensional array of bytes that somebody passes to your program, you’re most likely better off processing it in the format that it was given to you. Converting the data to your preferred “faster” format and converting it back to the native format is going to take a lot of time: probably more time than you’ll save with your “faster” processing code.

Even if you’re writing new code, the best array representation is almost always the one that best fits your model. A rectangular array (i.e. byte[,]) usually leads to simpler code, but jagged arrays (i.e. byte[][]) can be better in many situations. Jagged arrays are almost always better when you need an “array of arrays.” That is, when the second dimension is variable.

That said, let’s benchmark some simple operations with the two different types of arrays. The platform I’m using is:

• Windows Server 2008 R2
• Visual Studio 2012, Update 1
• Intel Xeon X5350 @ 2.67 GHz
• Program compiled in Release mode with “Any CPU”, targeting .NET 4.5
• Run in the 64-bit runtime with debugger detached

I have a simple test harness that runs the test method once to eliminate JIT effects (the time taken for the JIT compiler to compile the method), and then starts a Stopwatch and executes the test method the number of times requested. The reported time is the average of all those runs. Here’s the test harness:

    private void Test(Action a, string text, int numIterations)
    {
        Console.Write("{0} ... ", text);
        // do it once to eliminate JIT effects
        a();

        // Now time the iterations.
        var sw = Stopwatch.StartNew();
        for (var i = 0; i < numIterations; ++i)
        {
            a();
        }
        sw.Stop();
        Console.WriteLine("{0:N0} ms", sw.ElapsedMilliseconds/numIterations);
    }

In these tests, I’m using arrays that have 2,736 rows and 10,944 columns. This corresponds to the number of pixels in a 10 megapixel image, with each pixel taking up 3 bytes. The timings I report below are the average of running each method 1,000 times.

The first test is just a simple traversal of the array that sums all the values. I first wrote it like this:

    private int SimpleSum;

    private void SimpleSumRect(byte[,] array, int rows, int cols)
    {
        SimpleSum = 0;
        for (var i = 0; i < rows; ++i)
        {
            for (var j = 0; j < cols; ++j)
            {
                SimpleSum += array[i, j];
            }
        }
    }

    private void SimpleSumJagged(byte[][] array, int rows, int cols)
    {
        SimpleSum = 0;
        for (var i = 0; i < rows; ++i)
        {
            for (var j = 0; j < cols; ++j)
            {
                SimpleSum += array[i][j];
            }
        }
    }

After initializing the arrays, I run the tests like this:

    Test(() => SimpleSumRect(rectArray, ArrayRows, ArrayCols), "Simple Sum rect", NumIterations);
    Test(() => SimpleSumJagged(jaggedArray, ArrayRows, ArrayCols), "Simple Sum jagged", NumIterations);

The result was rather interesting:

    Simple Sum rect ... 70 ms
    Simple sum jagged ... 70 ms

No difference? I wasn’t really surprised by that, and almost dismissed the conventional wisdom as so much myth. But I was also curious because I have great respect for some of the people making the “jagged is faster” claim. So I modified the test slightly. Rather than summing to a variable at class scope, I made it a local variable, like this:

    private int SimpleSumRect(byte[,] array, int rows, int cols)
    {
        int SimpleSum = 0;
        for (var i = 0; i < rows; ++i)
        {
            for (var j = 0; j < cols; ++j)
            {
                SimpleSum += array[i, j];
            }
        }
        return SimpleSum;
    }

That result was surprising:

    Simple Sum rect ... 39 ms
    Simple sum jagged ... 24 ms

I had no idea that accessing a class-scope variable was so much more expensive than accessing a local variable. I’d have to look at the generated code (both IL and the JIT-generated machine code) to say for sure what’s going on here, but apparently accessing that class-scope variable prevents the compiler from making some optimizations. Making the sum a local variable (that the compiler probably keeps in a register) shows the real difference in the arrays’ performance. I thought the jagged array would be a little faster, but I certainly didn’t expect that much of a difference.

It’s pretty clear here that traversing a jagged array sequentially is hugely faster than traversing an equivalent rectangular array. The primary reason, it turns out, is array bounds checking. When accessing array[i, j], the runtime has to check the bounds of both indexes. You would think that it would have to do the same thing for the jagged array, but the compiler optimizes the code to something akin to this:

    private int SimpleSumJagged2(byte[][] array, int rows, int cols)
    {
        var SimpleSum = 0;
        for (var i = 0; i < rows; ++i)
        {
            var theRow = array[i];
            for (var j = 0; j < cols; ++j)
            {
                SimpleSum += theRow[j];
            }
        }
        return SimpleSum;
    }

So the inner loop only has to do one bounds check per iteration.

In addition, a simple array (i.e. byte[]) is treated differently. It is assumed to be 0-based, so that indexing is a matter of arrayBase + (index * size). The jagged array is a simple array of simple arrays, making indexing faster. See this Stack Overflow answer for a little more detail.

Rectangular arrays, on the other hand, can have non-zero bases. Not in C#, but the C# compiler generates code to be used by the runtime Array class implementation. Indexing into one of these arrays requires a little more math: arrayBase + ((i - dim1Base) * (size * cols)) + ((j - dim2Base) * size) (where dim1Base and dim2Base are the base indexes for each dimension). The compiler can optimize some of that, but it should be obvious that it can’t eliminate all of the extra work.

It’s important not to dismiss the first test as irrelevant. Whereas the second test shows that jagged arrays can be faster than rectangular arrays, the first test shows that other factors can easily defeat any potential gain realized by using the “more efficient” data structure. In this case, simply accessing a class-scope variable in the inner loop made the compiler optimizations meaningless.

I ran another test that modified each byte in the array. The idea here was to eliminate as much as possible all external factors. Here are the test methods.

    private void SimpleTraversalRect(byte[,] array, int rows, int cols)
    {
        for (var i = 0; i < rows; ++i)
        {
            for (var j = 0; j < cols; ++j)
            {
                array[i, j] = (byte)(255 - array[i, j]);
            }
        }
    }

    private void SimpleTraversalJagged(byte[][] array, int rows, int cols)
    {
        for (var i = 0; i < rows; ++i)
        {
            for (var j = 0; j < cols; ++j)
            {
                array[i][j] = (byte)(255 - array[i][j]);
            }
        }
    }

The timings are pretty much what you expect: 40 ms for the rectangular array and 24 ms for the jagged array.

Then I thought I’d do a little optimization myself by venturing into the world of unsafe code and pointers. The result looks more like C than C#, but it does show that you can optimize access to a rectangular array.

    private void OptimizedTraversalRect(byte[,] array, int rows, int cols)
    {
        long count = (((long)rows) * cols)/3;
        unsafe
        {
            fixed (byte* pArray = array)
            {
                byte* p = pArray;
                while (count-- > 0)
                {
                    *p++ = (byte)(255 - *p);
                    *p++ = (byte)(255 - *p);
                    *p++ = (byte)(255 - *p);
                }
            }
        }
    }

    private void OptimizedTraversalJagged(byte[][] array, int rows, int cols)
    {
        for (var i = 0; i < rows; ++i)
        {
            unsafe
            {
                int count = cols/3;
                fixed (byte* pArray = array[i])
                {
                    byte* p = pArray;
                    while (count-- > 0)
                    {
                        *p++ = (byte)(255 - *p);
                        *p++ = (byte)(255 - *p);
                        *p++ = (byte)(255 - *p);
                    }
                }
            }
        }
    }

The timings here are exactly what I expected: 24 ms for the rectangular array and 24 ms for the jagged array. Actually, the rectangular array version is slightly faster, on average, because it doesn’t have to do as much work. Interestingly, if I don’t unroll the inner loop (i.e. only do one operation per iteration), both versions take longer than the original, un-optimized rectangular array version. The compiler is smarter than you think. I was able to outperform the compiler here only because I know that the array’s width is a multiple of three, and it was safe to unroll the loop.

Note that there’s a reason that code is considered unsafe: using the pointer, I circumvent any array bounds checking. Between that and eliminating the indexing calculations, I made traversing the rectangular array a simple sequential walk through memory.

So jagged arrays are faster, right? Well … maybe. What happens if you access them (semi-) randomly?

    private const int Increment = 1009;
    private void RandomRect(byte[,] array, int rows, int cols)
    {
        int count = rows*cols;
        int row = 0;
        int col = 0;
        while (count-- > 0)
        {
            row = (row + Increment) % rows;
            col = (col + Increment) % cols;
            array[row, col] = (byte)(255 - array[row, col]);
        }
    }

    private void RandomJagged(byte[][] array, int rows, int cols)
    {
        int count = rows * cols;
        int row = 0;
        int col = 0;
        while (count-- > 0)
        {
            row = (row + Increment) % rows;
            col = (col + Increment) % cols;
            array[row][col] = (byte)(255 - array[row][col]);
        }
    }

The timings here are telling: 310 ms for the rectangular array and 412 ms for the jagged array. The reason for the huge difference has to do with how the two array types are represented in memory. The rectangular array is one big block of memory. The jagged array is one block of memory for an array of row references, and a separate block of memory for each row. Accessing an arbitrary element in a jagged array, then, requires two separate lookups in memory that can be scattered all over. The result is approximately twice as many cache misses for the jagged array when compared to the rectangular array.

I understand, of course, that my “random” traversal is hardly random. It does, however, provide scattered access to the array elements in a manner that simulates what truly random access would do. I actually wrote a version that used a random number generator, but it took much longer to run and gave almost the same behavior as this simpler version.

So the answer to the question of which type of array is faster is, as you’ve probably figured out by now, “It depends.”

If you can guarantee that external factors (like accessing a class-scope variable) won’t negate the compiler’s optimizations, then using a jagged array can be 40% faster than using an equivalent rectangular array. But if you’re accessing the array randomly, a jagged array can be 33% slower than a rectangular array. The question of which is faster is meaningless without context.

The machine I ran these tests on is pretty old. I’ve also run the tests on a Core i7 processor and obtained similar results. The absolute times were faster (the machine is running at 3.4 GHz), but the percentage difference in the speed of the two array types are similar.

Non-speed considerations

“Efficiency” means more than just raw speed. When discussing performance, we often find that speed and memory efficiency are inversely related. That is, doing something faster requires using more memory. That’s not always true, but it often is. If you’re concerned about efficiency you need to know not just how fast things are, but also how much memory they take and how that memory is allocated.

In addition to having different performance characteristics, jagged arrays and rectangular arrays are stored differently in memory. A rectangular array consists of a single allocation of size rows * cols * element-size, plus about 50 bytes of overhead for array metadata. A jagged array requires somewhat more memory. It consists of an allocation of size rows * sizeof(IntPtr) (plus metadata), and there is a separate allocation for each row, of size cols * element-size. So consider the array I showed above, which is 2,736 x 10,944. The difference in this large array is about 150 kilobytes, or less than one percent in this 30 megabyte array. Imagine, though, if the rows were only 50 bytes long. The jagged array would consume twice the memory of the rectangular array because the per-row overhead of 50 bytes still applies.

There are advantages to that distributed array representation, however. Prior to .NET 4.5, a rectangular array couldn’t occupy more than two gigabytes (slightly less, in reality). So an array of bytes with a million rows (actually, 2^20 rows) and 2,048 columns couldn’t be created. That is, byte[10^20, 2048] would produce OutOfMemoryException, regardless of how much memory you have on your machine.

But you could easily create a short[][] with 10^20 rows and 2,048 columns, because each row would be a paltry two kilobytes in size.

.NET 4.5 introduced the gcAllowVeryLargeObjects configuration file element that lets you allocate objects larger than 2 gigabytes, which alleviates some of the problems, but there are still restrictions as pointed out in the documentation. And it’s often impossible to get a huge chunk of contiguous memory, which the rectangular array needs. So there are still benefits to the jagged array.

So, which to use? Whatever best fits your model. I prefer rectangular arrays in most cases because I find them easier to work with (try initializing a jagged array) and easier to reason about. I also know that I can optimize my array handling code if I need to, using unsafe code and pointers. But every situation is different, and I’ll happily use a jagged array if the situation calls for it.

Only you can decide which array representation is appropriate for your application. You have to weigh the costs and benefits and pick the one that best meets your needs. Don’t immediately fall for the simplistic “jagged is faster” hype that’s all too often spouted as a matter of faith without understanding the wider implications.

By the way, most “Which is faster” questions . . . → Read More: How to time code]]> Many Stackoverflow questions amount to nothing more than, “Which of these is faster?” or “Why is this so slow?” Very often, the person posting the question will include code that outputs some timing results. More often than not, the timing code is just wrong. Sometimes fatally so.

By the way, most “Which is faster” questions are non-starters. You shouldn’t ask before you’ve done the benchmark yourself. Read on.

If you want accurate timing information, you have to do it the right way. If you do it the wrong way, your results will be at best unreliable. Fortunately, doing things the right way is pretty easy.

But before I go any further, I feel obligated to ask the most important question: Why do you care? Before you start adding code to profile small parts of your application, you need to ask yourself if it’s really that important. Or are you just wasting your time worrying about the performance of something that is already “fast enough?” I strongly suggest that you read Eric Lippert’s, Which is faster?

Now, if you really need to time your code. . .

The information below is for .NET, and the code samples are in C#. You should follow the same techniques if you’re writing in Visual Basic .NET or Managed C++, and probably any other .NET language. The general techniques are true of pretty much any other platform as well, although the specifics will be much different.

When doing benchmarks, run them against a release build with no debugger attached. In Visual Studio, be sure to select the Release build, and either press Ctrl+F5 to run, or select Debug -> Start Without Debugging. Timings gathered from a debug build or from having the debugger attached (even in a Release build) will be inaccurate. You’ll often find that there is little difference between Debug and Release builds when the debugger is attached.

Do not use DateTime.Now, DateTime.UtcNow, or anything else based on DateTime as your time source. There are two reasons for this. First, the resolution of DateTime is somewhat questionable, but probably not much better than 15 milliseconds. Secondly, the clock can change on you. I once had a bit of code take -54 minutes (yes, it completed 54 minutes before it started) to execute because it started four minutes before 2:00 AM on “Fall back” day (Daylight Saving Time autumn adjustment date) and finished six minutes later. So start time was 01:56:00 and end time was 01:02:00. You don’t control the system clock, so don’t depend on it.

Use the System.Diagnostics.Stopwatch class for all elapsed time measurements. That’s based on the Windows high performance timer, which is the most accurate interval timer you’re likely to get on a Windows box unless you have special hardware. Accept no substitutes.

With Stopwatch, timings are easy. First, add this using statement to the top of your source file:

    using System.Diagnostics;

Then, surround the code you want to time with a Stopwatch:

    Stopwatch sw = Stopwatch.StartNew(); // creates and starts the stopwatch
    //
    // put the code you want to time here
    //
    sw.Stop();  // stop the watch.
    Console.WriteLine("Elapsed time = {0} milliseconds", sw.ElapsedMilliseconds);

That’s all there is to it!

I usually like to report times in milliseconds (1/1000 second), simply because the usable range is reasonable. If I’m timing something that takes less than a millisecond to run, I need to do it many times to get a good average. A million iterations of any non-trivial loop will likely take longer than a few milliseconds. On the same note, a full day is 86,400 seconds or 86,400,000 milliseconds: a number that is still reasonably easy to work with. If I’m timing something that takes longer than a full day to run, I might decide to use seconds as my comparison.

One other nice thing about Stopwatch is that you can have many of them, each timing a discrete part of your program. For example:

    Stopwatch totalTime = Stopwatch.StartNew();

    Stopwatch pass1Time = Stopwatch.StartNew();
    DoPass1();
    pass1Time.Stop();

    Stopwatch pass2Time = Stopwatch.StartNew();
    DoPass2();
    pass2Time.Stop();

    totalTime.Stop();

You then have separate values for the total time and the time to execute each pass.

If you’ve done all of that and you still haven’t found an answer, then post a question. But include your timing code so that those of us who are willing to help you find an answer aren’t groping around in the dark. And be sure to mention that you ran in Release mode without the debugger attached.