Turn on double buffering

Turning on double buffering seems to solve the problem. Normally double buffering would only help reduce flickering, since painting is being done to an off-screen buffer, but for the DataGridView it also significantly reduces the amount of functions being called internally in the DataGridView – thus reducing processor load and increasing speed. (statistics gathered with the Eqatec Tracer)

My DataGridView doesn’t have a DoubleBuffered property !?!?

For some reason Microsoft has decided to hide the DoubleBuffered property from DataGridView. Luckily you can set it anyway with reflection.

public static class ExtensionMethods
{
    public static void DoubleBuffered(this DataGridView dgv, bool setting)
    {
        Type dgvType = dgv.GetType();
        PropertyInfo pi = dgvType.GetProperty("DoubleBuffered",
            BindingFlags.Instance | BindingFlags.NonPublic);
        pi.SetValue(dgv, setting, null);
    }
}

Just drop the above class into your project somewhere, or add the function to your existing extension methods.
The extension method allows you to set the DoubleBuffered property on your DataGridView in the following manner:

dataGridView1.DoubleBuffered(true);

You now have a smooth scrolling DataGridView

The ProcessPriorityClass

Setting ThreadPriority to one of the values possible with C# will only shift the priority of the thread up and down within a class of priorities shared by the whole process. This means that even setting ThreadPriority to ThreadPriority.Highest will not actually give the thread a high priority, compared to the system processes. It will only give the thread a high priority compared to other threads belonging to comparable processes.
I”l try to make it a bit clearer with this little css/ascii illustration

In C# processes start with normal priority, so setting ThreadPriority.Highest under normal conditions wont make the thread higher priority than ThreadPriority.Lowest in a process running with a high priority class.

Letting Windows know that you are really important.

Take a look at this code:

class Program
{
  static void Main(string[] args)
  {
    Thread t = new Thread(threadFunc);
    Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.RealTime;
    t.Priority = ThreadPriority.Highest;
    t.Start();
    Console.ReadLine();
    t.Abort();
  }

  static void threadFunc()
  {
    while (true) {}
  }
}

This code will make a thread/process that has the highest possible priority you can set with C#. Luckily i have a dual-core processor – otherwise that code would have frozen my computer. Now it only uses up one of my cores frantically checking if true is still true…
The magic here lies in assigning ProcessPriorityClass.RealTime to the current process. Note that this is done in a process-wide scope, and all the threads in the process will have their priorities adjusted to fit in the new priority range. You can not have threads with extremely high and extremely low priorities within the same process.

It is really cool – but don’t abuse it.

Do not run off and adjust the priorities of all your programs, to get the processing time they rightly deserve. Fixing problems by raising priorities are very often a symptom of some greater underlying problem in your code, and the correct way of fixing things are most often to remove the bottlenecks in your program, and leave the priorities alone. This holds especially true for ProcessPriorityClass.RealTime, since this will potentially block execution of critical system stuff like garbage collection or keyboard and mouse input.
I would recommend against using anything higher than ProcessPriorityClass.High

• Don’t concatenate strings – use a StringBuilder instead
• Whenever possible initialize the StringBuilder with enough capacity to avoid re-allocations
• Excessive concatenation of strings will be several orders of magnitude slower than using a StringBuilder
• String.Format() & StringBuilder.AppendFormat() are significantly slower than just using the +operator or Append() – but may be more readable
• When performance optimizing an application – string usage is a good place to start

Don’t concatenate strings

The StringBuilder is an often overlooked class, that can be used to solve a lot of performance problems in your applications.
To give an example of how ineffective the basic string can be, take a look at the following code that builds 2 large strings by concatenating 1000 times to the same string using String and StringBuilder:

string s = string.Empty;
for (int j = 0; j < 1000; j++)
{
  s += "Test of string performance.";
}

StringBuilder sb = new StringBuilder();
for (int j = 0; j < 1000; j++)
{
  sb.Append("Test of string performance.");
}

Performance is measured on my HTC S710 moblie phone. The performance difference is very noticeable.

• The String implementation takes about 800ms
• The StringBuilder implementation takes about 12ms

StringBuilder is almost 70 times faster than String in this particular example and initializing the StringBuilder with enough capacity up front will shave another 2ms off. I have done tons of optimizations on Compact Framework applications over the years, and the first thing i usually do is replace String with StringBuilder in code similar to the above example.

Immutable strings – blessing or curse?

Strings in the .NET framework are immutable – meaning that once they are created they can not be changed. It is a design decision from the .NET framework designers, that allows for a lot of optimizations, but also cost performance under certain circumstances.
This is the main reason the String concatenation from before is so slow. Every time the strings are concatenated, a new String is created, and the old one is left for the garbage collector. At least a thousand strings of increasing size are created, copied and garbage collected for no good reason. It is amazingly ineffective.

StringBuilder – definitely a blessing!

The StringBuilder is the thing to use, when handling and manipulating large strings. It holds the string in an internal array that it grows as needed. This enables a very fast append that only rarely allocates anything new. In my test the StringBuilder initially had a capacity of 64 bytes, and grew to double size whenever needed, but implementations may vary.
This behaviour means that you can optimize performance even further by initializing the StringBuilder to a size that is slightly larger than what you expect the final string to be – thereby removing the need to ever re-allocate.

A word or two about String.Format()

I always assumed that using String.Format() to splice strings with variables was the fastest way of doing it. Tests show, however, that it is not…
I have made test of 4 different ways of accomplishing the same thing:

//using string
string x = "Test of string performance." + 1 + 2 + "hello";
string x = string.Format("Test of string performance.{0}{1}{2}", 1, 2, "hello");

//using StringBuilder
sb.Append("Test of string performance.").Append(1).Append(2).Append("hello");
sb.AppendFormat("Test of string performance.{0}{1}{2}", 1, 2, "hello");

The results are similar for both the String and StringBuilder. Using the +operator or chained appends is roughly twice as fast as using the Format() method. This came as a bit of a surprise to me.