• 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.

• Write a dummy text file on startup, and check the existance of this file.
• Write to a registry-key on startup, and use that as a “mutex”.
• Use a named mutex with a system-wide scope.

Obviously the first two have the problem that they may break the program, if the program exits without resetting the file/registry-key used as a pseudo-mutex. They are also very crude and not very elegant…. But that’s up to personal taste i guess.
I went for the third choice; The named mutex.

The named mutex in Windows CE

The .NET Compact Framework does not support named mutexes. Luckily Windows CE does however, and it can be imported through a few functions in coredll.dll.
A named mutex is an object created by the OS with a name specified on creation. The actual functionality of the object is not very interesting right now. The interesting bit is that only one object can exist with any given name. If you try to create another object with the same name, you get an error.
Basically, if you create a named mutex with the name of the application itself, this can be used to ensure that only one instance of the application can be run.

Wrapping it up

I decided to wrap it all up nicely in a class, so that it will be easy to use. The class is called SingleInstanceApplication, and here is what i came up with:

using System;
using System.Windows.Forms;
using System.Runtime.InteropServices;
using System.Reflection;

namespace Bitmatic
{
  static class SingleInstanceApplication
  {
    [DllImport("coredll.dll", SetLastError = true)]
    public static extern IntPtr CreateMutex(IntPtr Attr, bool Own, string Name);

    [DllImport("coredll.dll", SetLastError = true)]
    public static extern bool ReleaseMutex(IntPtr hMutex);

    const long ERROR_ALREADY_EXISTS = 183;

    public static void Run(Form frm)
    {
      string name = Assembly.GetExecutingAssembly().GetName().Name;
      IntPtr mutexHandle = CreateMutex(IntPtr.Zero, true, name);
      long error = Marshal.GetLastWin32Error();

      if (error != ERROR_ALREADY_EXISTS)
        Application.Run(frm);

      ReleaseMutex(mutexHandle);
    }
  }
}

Feel free to steal….
The class imports the two native functions for creating and destroying mutexes, and has only a single public function.
The Run function tries to create a mutex with the name of the application. It then checks the error code returned, to see if the mutex already exists, and if it doesn’t; starts the application. Finally it releases the mutex.
Very simple, and quite a bit more elegant than the file/registry based solutions.

Using it

Using the class is very very simple. Just add the class itself to your project, open up Program.cs and replace:

[MTAThread]
static void Main()
{
  Application.Run(new Form1());
}

with:

[MTAThread]
static void Main()
{
  SingleInstanceApplication.Run(new Form1());
}

You only really changed one line, and now you have an application that is guaranteed to run only as a single instance.

A long search has ended

I have been looking for something like this for several years, but until the Eqatec profiler, no profiler has been able to profile mobile applications. When working with the Compact Framework you often find yourself in situation where performance is an issue. Many times you can make educated guesses as to where the bottlenecks may be, but at other times you are left pretty clueless.
Attach a decent profiler, and your bottlenecks will be clear as ice.

Does it work?

When the Eqatec profiler was released I immediately put it into work with profiling an application that had some performance issues during initial startup. We had tried solving these by guesswork, but it hadn’t helped a lot.
Within 2 hours of attaching the profiler, I had cut the startup time to a fraction of what it was before.

There is a small issue that you need to be aware of with this profiler. Because of the way it works, by instrumenting the code, it adds a little bit of overhead to every function call. This means that small functions that get called a lot will appear to be more time consuming than they really are, because most of the time used is actually the overhead. This is something to look out for, when deciding which functions to try to optimize. It would be really nice if Eqatec could find a way to compensate for this overhead.

Other than that the profiler works like a charm. And by the way – I am not paid to write this, I just like the product a lot.