Bjarne Juul Pasgaard

I’ve recently been working with the .NET Compact Framework 3.5 on Windows CE 6.0 for a customer of mine. The .NET Compact Framework is frequently referred to as a sub-set of the full .NET framework. In reality, there are more differences, however.

Overall, the Compact Framework seems to have been crafted with one single strategy; reduced code-/ram-consumption. The garbage collector is therefore working differently. The JIT compiler may also have to compile the same code multiple times because the result of earlier compilations may have been thrown away by the garbage collector. Also, no virtual tables are used. Virtual calls are based on a search-algorithm. Many other differences are documented in Microsoft slide show with the title “MED 301 Developing High Performance Applications with .NET Compact Framework”.

The effect is that many constructs that are acceptable in terms of performance in the full .NET are less optimal in Compact Framework. A virtual method call, for example, has a significantly higher cost (roughly a factor of 1.4) in execution time than a non-virtual call. Of course, it is not a big surprise that a virtual call has a higher cost than a non-virtual call; that’s already known from C++ and also applies to the full .NET framework. The cost is, however, higher in the compact framework.

I helped create a teaser on this while we were working on the project. It’s in danish, I’m afraid, but the solution comes with some interesting measurements that are worth looking at.

Microsoft may well be right that embedded systems typically have less memory than desktops and servers and one therefore needs to be more cautious when coding for embedded systems. But many embedded systems also have significantly less CPU power and are often powered by a battery. So the CPU cycles also matter. And as of this writing, there are no tools available to compile a .NET Compact Framework application to native code for a Windows CE 6.0 device (again, Microsoft’s argument is that the resulting code takes up more space).

If we disregard usability issues, application speed perhaps matters the least in UI-applications. Perhaps Microsoft intended to target their compact framework entirely for UI-applications?

But then, as the range of UI controls, properties, and methods available in the compact framework are far less than those in the full framework, you can only make the most simple UI’s in the compact framework, unless you write your own replacement for Windows.Forms (see e.g. Creating a Compelling UI for Windows Mobile and the Microsoft .NET Compact Framework or Building Graphically Advanced Applications with the .NET Compact Framework 3.5) – and that’s not a small amount of work.

This all makes porting of an application from the full .NET framework to the compact framework non-trivial. Personally, I also feel that the closed-source nature of the .NET framework makes it more difficult to write optimal code.

Add to this that you need both a license for Visual Studio 2005 (to build Windows CE 6.0) and Visual Studio 2008/2010 (to build the .NET application).

All-in-all, my conclusion is; think twice before you embark on the .NET Compact Framework.