Use StringBuilder for Complex String Manipulation

When a string is modified, the run time will create a new string and return it, leaving the original to be garbage collected. Most of the time this is a fast and simple way to do it, but when a string is being modified repeatedly it begins to be a burden on performance: all of those allocations eventually get expensive. Here's a simple example of a program that appends to a string 50,000 times, followed by one that uses a StringBuilder object to modify the string in place. The StringBuilder code is much faster, and if you run them it becomes immediately obvious.

namespace ConsoleApplication1.Feedback{   using System;    public class Feedback{    public Feedback(){      text = "You have ordered: \n";    }    public string text;    public static int Main(string[] args) {      Feedback test = new Feedback();      String str = test.text;      for(int i=0;i<50000;i++){        str = str + "blue_toothbrush";      }      System.Console.Out.WriteLine("done");      return 0;    }  }}

namespace ConsoleApplication1.Feedback{   using System;  public class Feedback{    public Feedback(){      text = "You have ordered: \n";    }    public string text;    public static int Main(string[] args) {      Feedback test = new Feedback();      System.Text.StringBuilder SB =         new System.Text.StringBuilder(test.text);      for(int i=0;i<50000;i++){        SB.Append("blue_toothbrush");      }      System.Console.Out.WriteLine("done");      return 0;    }  }}

Try looking at Perfmon to see how much time is saved without allocating thousands of strings. Look at the "% time in GC" counter under the .NET CLR Memory list. You can also track the number of allocations you save, as well as collection statistics.

Tradeoffs   There is some overhead associated with creating a StringBuilder object, both in time and memory. On a machine with fast memory, a StringBuilder becomes worthwhile if you're doing about five operations. As a rule of thumb, I would say 10 or more string operations is a justification for the overhead on any machine, even a slower one.

Precompile Windows Forms Applications

Methods are JITed when they are first used, which means that you pay a larger startup penalty if your application does a lot of method calling during startup. Windows Forms use a lot of shared libraries in the OS, and the overhead in starting them can be much higher than other kinds of applications. While not always the case, precompiling Windows Forms applications usually results in a performance win. In other scenarios it's usually best to let the JIT take care of it, but if you are a Windows Forms developer you might want to take a look.
Microsoft allows you to precompil