Dallas, June 5, 2003 – A hot topic is performance of managed applications. Although mainly targeted towards desktop applications, there certainly is a lot that smart device developers can do as well. Probably it is even more important for device developers to develop with performance in mind, since we often use slower processors and have much more memory constraints. During TechEd there have been quite a few presentations with performance as subject, ranging from load time performance via memory performance to execution performance. Since most of these presentations covered desktop development and since there has not been time to investigate all the subjects for smart client applications we will describe one rather simple example where performance of a smart client application can improve dramatically. Inside Microsoft developers hear lots of complaints about performance of managed applications. There is even a team dedicated to CLR performance. Jan Gray is an Architect working for that team. Gray gave a presentation about writing faster managed code. According to Gray the .NET runtime is usually not responsible for bad performing applications. Most of the time performance issues are introduced because developers are not really thinking about performance until very late in the development phase. Bad performing applications often disguise themselves by making use of splash screens and wait cursors. Funny enough quite some Microsoft applications make use of a splash screen, look for instance to Visual Studio.NET starting. Developing software while keeping performance in mind means that performance issues should already be addressed during the requirements phase of a software project. Because it is extremely simple to develop managed applications for a .NET environment developers tend to add more and more functionality without thinking about performance. Despite the fact that machines are becoming faster and faster we should still keep the following in mind according to Gray: “Don’t do anything in your application unless you absolutely have no other choice”. Whenever performance problems arise in a managed environment chances are big that somewhere Garbage Collection is involved, with the exception of the initial load time of an application. Too often we rely on the Garbage Collector to do all kinds of work that should not really be necessary. Whenever developers think a little longer about their solution, much performance problems can be avoided. Performance problems in unmanaged code are solved relatively easy, because many developers have years of experience in an unmanaged world. In the managed world we are basically all newbies, because .NET has only be around for a few years. All of us still have to learn how to write efficient, performing code for a managed environment. One way to achieve this is to understand how compilers generate Intermediate Language and how that Intermediate Language is translated by the JIT compiler to native code. The only way to understand this process is actually studying IL and generated native code. Whenever a managed application performs bad we all want to blame the .NET runtime. Take a look at the newsgroups and everybody knows what Gray means. Right now, most of us are lacking something like “The Knowledge”, the exam for London cab drivers. All of us .NET developers should pass a similar exam, or at least have the knowledge of what we can and can not do. Many developers don’t realize that using objects does not only consume memory, but also time, because the Garbage Collector has to visit each object every now and then to find out if it is still in use. Therefore, it is not the best idea to create a huge amount of small objects and to use many layers of abstractions. This is true both for desktop applications and for smart device applications. To illustrate this, consider the following example. The application shown here is in itself useless, but it shows clearly the impact of well designed and bad designed code as far as performance is concerned.

Under both buttons the execution time in seconds for two different functions is shown. Both functions append 2500 date/time strings in a loop to one single string variable. The first function does so by declaring a string variable and appending a date/time string in a loop (see listing 1). The code, generated for this function will generate a new temporary string object, each time a date/time string is added to the destination string. Since the temporary strings become obsolete almost immediately, they are ready to be garbage collected. The function is really stressing the Garbage Collector, since 2500 new objects are created that eventually should all be deleted as well.