San Diego, May 26, 2004 – Today many of the talks at Tech*Ed, at least those that I attended, had somehow to deal with performance of managed applications. Looking at the number of people showing up at the talks this is an important topic. The first speaker of the day, Mike Henderlight, started by telling the audience that performance improvement is a priority task at Microsoft. However, dealing with performance issue is a shared responsibility and not something that Microsoft can solve alone. Careful coding can actually today result in good performing applications that are as good as native applications. According to Henderlight the Common Language Runtime is very good and fast, once an application is up and running. To look at the performance of an application it is not smart to use task manager, because the CLR will try to give an application as much memory as it can. Since DotNETForDevices mainly reports about smart devices and the .NET Compact Framework you have to keep in mind that Henderlight is talking about the full .NET Framework, the situation for the .NET Compact Framework is different. At the same time, many performance issues apply both to the full and the compact framework. Henderlight told the audience that performance is really poor when cold starting an application. Of course this is nothing new, I am sure that everybody has experienced that a couple of times. The reason for this poor performance is the fact that not only the application needs to be loaded, but the CLR needs to be bootstrapped as well. With the arrival of the next version of the .NET Framework, cold start performance should improve significantly, even though a big part of the performance issues with cold starts is disk bound, not CPU bound. Henderligth gave some obvious tips & tricks. Even though many of these things are not really news for developers, it is still a good thing to repeat them over and over. The first one is perhaps the truest one. Don’t work until you absolutely have to. In other words, do as little as you can, preferably nothing at startup. The best performing application is an application that actually does nothing! Even though we all know this, how often are we not tempted to add in useless functionality, just because of the fact that we want to show what kind of cool things we can create.

Something very important and perhaps not really obvious is the fact that throwing exceptions is expensive. It is absolutely a bad idea to throw exceptions as a replacement for function return values. Exceptions should only be thrown in exceptional situations, I guess the name exception was well chosen and really does make sense.

Specific to WinForm applications it is important to batch operations as much as possible. For instance, when filling a ListBox it is really helpful to call BeginUpdate first, then populate the ListBox, followed by EndUpdate. Calling BeginUpdate prevents against a whole bunch of paint messages to be send to the form. Take for instance this code snippet:

private void button1_Click(object sender, System.EventArgs e)
{
    for (int i = 0; i < 100000; i++)
    {
        listBox1.Items.Add(i.ToString());
    }
}

To execute this piece of code would take around 10 seconds, at least on the machine I am performing the test. A big amount of that time is spent in painting the contents of the ListBox, even though we are simply filling it. Simply preventing it from painting everytime, as shown in the next snippet, reduces the execution time to around one third of the original snippet.

private void button1_Click(object sender, System.EventArgs e)
{
    listBox1.BeginUpdate();
    for (int i = 0; i < 100000; i++)
    {
        listBox1.Items.Add(i.ToString());
    }
    listBox1.EndUpdate();
}

In cases where heavy graphics operations are necessary, performance is even more critical. In those situation techniques like double buffering and only repainting clipping areas dramatically help increase performance. This is most likely beyond the scope of average smart device applications, although these applications might benefit as well.

Specifically focused to performance of the.NET Compact Framework Scott Holden’s talk. He started off with a very wise remark. It is absolutely necessary to make performance a functional requirement. Too often, performance issues are only dealt with at the end of development and it is way too late to come up with clean solutions for performance problems at that time. A couple of things to keep in mind are:

• Less code is faster code;
• Fewer objects are better for performance, especially on devices;
• Batch work where possible, for example it is much better to retrieve a whole array of data in one single call to a Web Service instead of calling many times into the Web Service to retrieve individual items;
• Think about asynchronous actions and multi-threading

With the arrival of the .NET Compact Framework 2.0 in the first half of next year performance will improve dramatically. Amongst others, exactly the same JIT compiler technique will be used to target all different processors. Right now only the ARM JIT compiler is optimized, for instance by executing ‘small’ methods inline. It is also important to realize when the garbage collector becomes active. Generally it will start its work when around 750 Kbytes of garbage collectable objects are created. This is an important reason to limit the number of objects you are using whenever you can, especially because garbage collection is a very expensive operation.

With the garbage collector in mind it also helps not to use finalizers. Especially for people who are used to C++ this is something to be aware off. Whenever a C# object contains a destructor, the garbage collector puts the object in a finalize queue because some operations might still need to be executed. Only during the next garbage collection, the object will actually be removed. This means that the garbage collector needs to visit the object twice, but also that it is totally unpredictable when an object is finalized. When finalization is necessary the advice is to implement the IDispose interface.

To measure performance in a Compact Framework application there are not many tools available right now. There is one useful tool that keeps performance statistics. It simply stores a number of stats in a file and can be enabled by setting a registry entry. More information about these so called perf counters can be found in this FAQ.