Steven Pratschner's .Net CF WebLog : NetCF General

.Net Compact Framework Performance Webcast

stevenpr — Tue, 14 Aug 2007 20:53:00 GMT

Last week I did an MSDN webcast on writing high performing device applications using the .Net Compact Framework. The webcast contains both in depth information on the internal workings of the Compact Framework and a set of tips and tricks for optimizing performance in everything from user interface to collections to networking. Here's the URL: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032345907&Culture=en-US .

Also, I had promised those viewing the webcast live that I would post the "generics" slide without the performance numbers overlaying the code. Here it is:

Thanks,

Steven

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

The Design of the .Net Compact Framework CLR, Part 1: Overview and Background

stevenpr — Tue, 13 Dec 2005 02:09:00 GMT

In the last few weeks I've been working on a series of posts that describes why various design decisions were made when building the .Net Compact Framework CLR. In this first post, I describe the environmental factors that have influenced the design and provide an overview of how the CLR manages memory. Subsequent posts will follow with details on the main design tenants of the JIT compiler, garbage collector, and class loader as well as information about how to analyze the memory usage of your Compact Framework application.

Throughout the series I'll be noting design decisions made when building the Compact Framework's CLR that are quite different than those made when building the CLR in the full .Net Framework.

---------

On the surface, the .Net Compact Framework appears to be a direct port of Microsoft’s .Net Framework runtime environment. At the high level, the similarities between the two products are intentional and provide many benefits. Both the Compact Framework and the full .Net Framework have the same programming model, use the same file format, share the same compilers, and so on. The primary benefit in having the two programming environments so similar is developers that have learned to program in one environment can quickly become productive in the other. For example, it takes almost no time for a developer familiar with the .Net Framework to write his first device application using the .Net Compact Framework.

Despite these similarities on the surface, when you look under the covers you’ll see that the implementation of the Compact Framework, especially its CLR component, is drastically different than its desktop counterpart. Not surprisingly, the environment in which the Compact Framework runs has directly influenced the architecture of its key internal components. The two environmental factors that have most influenced the way the Compact Framework CLR is built are the requirement to run in small amounts of memory, and the need to be portable across both processor types and operating systems.

This series of posts describe the internals workings of the CLR by looking at how the constraints in which it must run have influenced its design. Throughout the series I’ll point out where the design of the CLR has intentionally diverged from that of the desktop in order to run managed code in memory constrained environments.

Understanding the internals of the CLR may seem like an esoteric topic, but a deeper knowledge of how the platform works underneath your application will give you a better understanding of how your application uses resources on the device and how to diagnose problems related to memory usage or performance when they occur.

The Compact Framework runs on a number of different operating systems, but the largest installed base runs on Windows CE. Let’s start by taking a look at the Windows CE memory architecture. Understanding the services that the underlying operating system provides to the Compact Framework establishes a basis for understanding why the Compact Framework team made the design decisions they did when building the CLR.

The Windows CE Memory Model

As a 32 bit operating system, Windows CE can address 4GB of virtual address space just as the desktop versions of Windows can. However, the way in which this address space is partitioned has a direct affect on the architecture of Windows CE applications. The primary constraint, and the most common reason for Windows CE applications to experience memory problems, is that each application is granted just 32 MB of virtual address space. Memory can be allocated outside of this 32 MB space, but that memory is global to all applications on the device - it is not private to the application that allocates the memory. The description of the memory model presented here is an overview aimed at those aspects of Windows CE that we’ll need to understand as we explore how the Compact Framework uses memory. A more detailed description of the Windows CE memory model can be found in the Microsoft Press book “Programming Windows CE” by Doug Boling.

The following figure shows how Windows CE partitions the memory available for use by applications.

Figure 1
Memory available to Windows CE applications

As can be seen, there are 3 address space partitions that come into play when an application runs:

System Code Space. The read-only code pages for all system dlls, such as coredll.dll, are loaded into this space. There is one system code space per device so all applications share the code pages for the system dlls. Windows CE can page portions of this memory to storage and pull them back later if needed.
Per-Process Address Space. As described, each Windows CE process is allocated 32 MB of virtual memory. The stack for each thread in the application, the code pages for the application’s executable files, and any heaps allocated and used by the application are among the elements stored in this space.
High Memory Area. The 1GB high memory area provides virtual address space from which requests for large amounts of virtual memory can be satisfied. Any calls to VirtualAlloc that request more than 2GB of virtual memory will be satisfied out of this space. In addition, all memory mapped files are stored in high memory. All data stored in the high memory area is visible to applications on the device. Windows CE can swap pages from the high memory area to storage and back if needed.

The .Net Compact Framework uses memory from all three of these partitions when running an application. As we’ll see, it is Compact Framework’s aggressive management of the per-process address space that provides the most benefit to developers of managed applications.

.NET Compact Framework Memory Management Basics

Increased developer productivity is one of the main reasons driving the broad adoption of both the .Net Framework and the .Net Compact Framework. Discussions about how the CLR contributes to developer productivity often focus on features like automatic memory management (garbage collection), processor independence and so on. While the Compact Framework definitely provides these benefits, it also provides additional features to help make developers more productive on devices. In particular, the .Net Compact Framework CLR manages the memory in the per-process 32 MB virtual address space on behalf of the developer. By insulating the developer from having to worry about when to allocate and free memory in order to keep their application running well within the 32 MB limit, the Compact Framework makes it much easier to write applications that behave well on memory constrained devices. As we’ll see throughout this series of posts, many of the key design decisions made when building the .Net Compact Framework CLR were made in order to efficiently manage the 32 MB per-process virtual memory limit. Said differently, the fact that Windows CE restricts each process to a relatively small virtual address space has caused the Compact Framework team to design a platform that enables applications to run well given the constraints of the environment.

Before describing the specific design decisions made to run on memory constrained devices, we need to summarize all the runtime data the operating system and the CLR create when executing a managed application. After I’ve described the categories of data required to run an application, I’ll show where the CLR allocates the runtime data relative to the Windows CE memory partitions described above. Consider the categories of runtime data that will require memory when the following simple “Hello World” application is run.

using System;
using System.ComponentModel;
using System.Drawing;
using System.Text;
using System.Windows.Forms;

namespace HelloDevice
{

public class Form1 : Form
{

    private MainMenu mainMenu1;
    private Label label1;

    public Form1()
    {
        InitializeComponent();
    }

    private void InitializeComponent()
    {
        this.mainMenu1 = new System.Windows.Forms.MainMenu();
        this.label1 = new System.Windows.Forms.Label();

        // Position the label
        this.label1.Location = new System.Drawing.Point(64, 81);
        this.label1.Size = new System.Drawing.Size(100, 20);
        this.label1.Text = "Hello Device!";

        // Size the form
        this.AutoScaleDimensions = new System.Drawing.SizeF(96F, 96F);
        this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Dpi;
        this.ClientSize = new System.Drawing.Size(240, 268);
        this.Controls.Add(this.label1);
        this.Menu = this.mainMenu1;
        this.MinimizeBox = false;
        this.Text = "Simple App";

    }

}

    static class Program
    {
        static void Main()
        {
            Application.Run(new Form1());
        }
    }

}

As you can see, this program creates a form with a single label containing the text “Hello Device!”. I’ve grouped the memory used at runtime into the following 6 categories:

Native code pages for the CLR dlls. The Compact Framework CLR consists of two dlls, mscoree.dll and mscoree2_0.dll. These dlls along with the native portion of the Compact Framework’s Windows Forms implementation, netcfagl2_0.dll, are considered system dlls. As a result, the code for these dlls is loaded into the system code space.
Application and Class Library assemblies. The CLR must load all of the IL code for both the application and for the class libraries it uses into memory so the JIT compiler has access to the IL it needs when generating the corresponding native code instructions and the class loader has access to the metadata it needs when laying out the data structures that describe the types and so on. In addition to the assembly containing the “Hello World” code, the listing above also requires the IL for mscorlib, System, System.Windows.Forms and System.Drawing. The files containing these assemblies are memory mapped into the high memory area as they are needed.
JIT-compiled native code. As an application is executing, the JIT compiler is called upon to generate the native code for each method that is accessed. This native code is stored in a buffer in the per-process virtual address space.
Allocated reference types. The listing above allocates numerous reference types. In addition to the main form itself, instances of MainMenu, Label, Point, and Size are created. More types are likely allocated within the implementation of the class libraries as well. The memory for all reference types comes from the garbage collector’s heap. The GC heap is a per-application heap stored in the address space specific to the application.
In-memory representation of type metadata. As classes and their methods are needed during the execution of a program, the CLR reads their metadata representation from the copy of the assembly mapped into the high memory area. The metadata is used to generate an in-memory representation of the classes and their methods. This representation is stored in a heap called the AppDomain heap. The AppDomain heap is stored in the per-process virtual address space.
Miscellaneous allocations. In addition to the categories of allocations described above, the CLR generates a small amount of additional data as it runs an application. The data in this category includes stubs that the JIT compiler uses to determine whether a method has been compiled and other short-lived data elements.

Now that we’ve seen the categories of data needed to run a managed application, let’s map those allocations back to the Windows CE memory model described earlier. Figure 2 shows which of the Windows CE memory partitions are used to store each category of runtime data.

Figure 2
The mapping between Compact Framework memory allocations and the Windows CE memory model.

In looking at Figure 2, it’s important to note which memory allocations have a per-process cost and which are shared among all processes. Recall from our discussion of the Windows CE memory model that the code pages in the system code space and all allocations made in the high memory area are shared among all applications, while all allocations made in the per-process space are private to that process. Because the per-process costs are not shared, it’s important to focus on making wise use of each process’s 32 MB of virtual address space. As a result, most of the design decisions we’ll look at throughout the rest of this series are those that affect the heaps that store jitted code, reference types, in-memory type representations and the various smaller allocations the CLR makes from the per-process area. For more information on the expected size of these per-process heaps, see Mike Zintel's post on Advanced Compact Framework Memory Management.

Now that we've covered the basics, the next post will describe some basic design tenants of the .Net Compact Framework's JIT compilers.

This posting is provided "AS IS" with no warranties, and confers no rights.

Why Upgrade to Version 2.0 of the .Net Compact Framework?

stevenpr — Wed, 30 Nov 2005 21:30:00 GMT

Much has been written about the new technical features available in version 2 of the .Net Compact Framework. In this post, I've tried to take a "higher level" approach by describing the product in terms of the benefits it can bring to a organization. This post is targeted at those who are currently analyzing whether to upgrade from version 1 of the Compact Framework to version2.

-------------------------------------------

The introduction of the new version of a software platform often causes enterprises to go through an analysis to determine whether the benefits realized in the new platform will offset the costs of upgrading. Version 2.0 of the .Net Compact Framework represents the experience gained by working with customers since the initial version was released in early 2003. During that time, the Compact Framework team has made significant investments in performance, developer productivity, stability, supportability and new features that make this release very compelling. This document describes the new capabilities of the Compact Framework from the perspective of an enterprise analyzing the business justification for upgrading.

Applications run faster

Increasing application performance was a primary goal of version 2.0 of the .Net Compact Framework from the very beginning. Investments were made in every product area to ensure that applications run faster across the board.

In some cases, performance increases were obtained by tuning existing code paths that had proven to be critical to performance. In other cases, entire areas of the product were substantially reworked to significantly increase performance. Many of these investments were made at the lower levels of the product in order to improve the overall performance of all applications, regardless of which features they use the most. For example, significant changes were made to the way the .Net Compact Framework allocates memory. In version 1.0, the Compact Framework could allocate approximately 1 million small objects per second. Due to changes in the memory allocation scheme, version 2.0 of the Compact Framework now allocates 7.5 million small objects per second. Performance gains on a similar scale have also been achieved for other common low level tasks necessary to run an application, such as compiling code, calling methods and on.

These key changes to low level algorithms, along with some targeted performance work in other areas of the product, have a direct affect on application-level tasks such as accessing data and calling web services. For example, a typical data access test used by the Compact Framework team completes in just over 3 seconds in version 2, while the same test took 13 seconds to run in version 1. Web Service performance is also up measurably in version 2. The overall performance of a Web Service call can vary drastically with network conditions and other external factors, but in general the cost of making a Web Service call is up on the order of 50%.

The performance improvements seen for your application depends in part on how it is built, but in general applications start faster and run much faster on version 2.0 of the Compact Framework.

Developers are more productive

Developer productivity has always been a hallmark of the .Net programming model. Concepts such as automatic memory management have been a key enabler of developer productivity since the inception of the .Net Compact Framework.
Developers are more productive when fewer steps are required, and there is less code to write to accomplish common tasks. Productivity is increased even more when the underlying platform provides built in implementations for those steps that are typically error prone. Such infrastructure increases productivity in the long run by reducing the occurrence of common programming mistakes.
Version 2.0 of the Compact Framework helps increase developer productivity in four key ways:

New programming language features. C# and VB.Net language features such as generic types and anonymous methods reduce the amount of “boilerplate” code a developer needs to write. Generally speaking, the less code the developer needs to write, the more maintainable the system is and the better it performs.

Enhanced infrastructure for calling existing code. Most .Net Compact Framework programs access existing native code components as part of the overall application solution. In version 1 of the Compact Framework, developers often had to write custom code that transferred data between the C# or VB.Net program and the existing native components. Not only was this additional code to write by hand, but it was often complex and error prone. Version 2.0 of the Compact Framework provides new infrastructure such that the instances in which developers had to write custom code to interoperate with native components is dramatically reduced or completely eliminated.

Extensions to the base class libraries. One of the reasons developers are so productive on the .Net platform is the existence of a vast set of class libraries that can be reused to perform common tasks. In version 2.0, the .Net Compact Framework provides a broader set of class libraries than it did in version 1.0. After version 1.0 was broadly adopted, the Compact Framework team did extensive customer research to determine which additional classes were most commonly requested. Some of the additions are extensions to already existing portions of the class library. For example, several new properties, methods and events were added that make it easier to interact with user interface controls. In some cases, however, the class libraries that were added make it possible for C# and VB.Net applications to directly access entirely new features. For example, the addition of the System.Messaging namespace makes it much easier to write an application that behaves well in transiently connected scenarios by taking advantage of durable messaging. For example, applications that transfer data only when they are cradled are now much easier to write and much more reliable.

Improvements in the visual editors. Microsoft Visual Studio allows developers to author portions of their applications using graphical editors rather than by writing code. Developers have an even more productive authoring experience in Visual Studio 2005 through improved graphical layout tools, new emulator support, the ability to reuse common snippets of code and so on.

Applications are easier to debug and support

A key element in an organizations ability to control overall systems cost is the degree to which a product can be supported after it has been deployed. .Net Compact Framework version 2.0 adds numerous new capabilities that make it much easier for developers and support personnel to determine what has gone wrong when a user encounters an error. These new capabilities include application tracing and logging, a new set of performance monitoring tools and the facilities to help developers accurately pinpoint errors in their code.

Most .Net Compact Framework subsystems now include some form of logging. Logging can be enabled to trace data elements such as network traffic, the interaction between C# or VB.Net code and native components, and other internal workings of the Compact Framework. These logs can help identify both applications errors and inconsistencies in the environment the application is running in.

Device applications must be conscious of the resources they use because devices typically have much less computing power and resources than desktop computers. Without good diagnostic tools, it’s very hard to determine what is causing an application to work poorly when resources are low. Fortunately, .Net Compact Framework version 2.0 provides performance monitoring data and a graphical tool that allows that data to be analyzed in real time. These tools enable a developer or support person to directly see how the application is using resources and where the bottle necks are. The following graphic shows how the Windows Performance Monitor can be used to understand the memory usage patterns of a .Net Compact Framework application running on a device.

When errors do occur in code, the .Net Compact Framework helps the developer isolate the error by providing a “stack trace”. A stack trace is a textual description that shows the developer exactly where in the program an error occurred.

The .Net Compact Framework team continues to invest in debugging and diagnostic tools. As more tools are added in subsequent releases, these tools will target version 2.0. No further diagnostic tools are planned for version 1.0.

Developing secure applications is much easier

Application security is a concern for all enterprises given the proprietary nature of the data needed to run the business. Developing secure applications is easier with Compact Framework version 2.0 in 3 ways. First, the Compact Framework runtime is more tightly integrated with the Windows CE security model such that the possibility of loading unsigned code can be eliminated. Second, the support in Visual Studio to debug a trusted device is completely automated. Visual Studio can be configured to sign all binaries before deploying them to the device for debugging. The third way in which .Net Compact Framework 2.0 makes it easier to build more security applications in the presence of a new set of cryptography class libraries. These class libraries simplify common cryptography tasks such as encrypting data and digitally signing files.

Access to Data is faster and more scalable

Most all enterprise device applications store data locally on the device. In many cases, data is kept on the device only temporarily until the device is connected to a network or cradled. Access to data is typically a performance critical operation if for no other reason than the data typically has to be loaded from storage such as a flash card or other media.

SQLMobile is a popular choice for storing data on a device. Applications that use .Net Compact Framework version 2 can take advantages of several new features in SQLMobile 2005 aimed at making access to data faster and more scalable. Accessing data through SQLMobile 2005 is made faster through a software component called the SqlCeResultSet. In most cases, accessing data using Compact Framework 2.0 and the SqlCeResultSet is several times faster than accessing data using previous versions of the .Net Compact Framework. Much of the performance gain realized by the SqlCeResultSet are the result improved algorithms that eliminate the need for data to be copied multiple times as it is read from the database and made accessible to the application.

The following chart shows the increase in performance achieved using .Net Compact Framework version 2 for some typical data access and XML tests.

Increased performance is not the only benefit available to applications that access data using version 2 of the .Net Compact Framework. Applications are also able to achieve much greater scalability due to support for multiple users and multiple database connections in SQLMobile 2005. These new features allow an application to have multiple data access requests outstanding simultaneously, thus reducing the need to wait until one request is done before starting another.

Developing applications that access data is also made much easier by new design features in Visual Studio 2005. The use of data design tools allow a developer to author the data access portions of the application graphically instead of writing custom code. The use of data designers is one more example where Visual Studio 2005 and .Net Compact Framework version 2.0 reduce the code that developers need to write in order to accomplish common tasks.

Developers can build more sophisticated user interfaces

Improvements to the display hardware on devices coupled with support for additional controls and graphics capabilities in the latest versions of Windows CE and WindowsMobile provide an underlying platform that supports the development of very sophisticated user interfaces. .Net Compact Framework version 2.0 makes these advances accessible to VB.NET and C# applications by providing support for the most recent user interface controls, graphics programming interfaces, and screen orientations.

New controls in version 2 of the Compact Framework include those to help organize and browse documents and web sites and to select dates and times. The addition of controls such as these enables developers to build more user interfaces “out of the box” without having to write or buy as many custom controls. However, should the need to write a custom control arise, Visual Studio 2005 makes it easy by providing visual support in the development environment for writing controls that satisfy a need specific to your application.

Applications can also display sophisticated 3 dimensional graphics, such as those used in games, through a .Net interface to the Direct3D graphics library.

The Compact Framework now also makes it easier to write user interfaces that must work on a variety of screen resolutions and orientations. For example, support for “docking and anchoring” enables a developer to write an application whose user interface dynamically adjusts when the screen orientation or resolution changes on a device.

Platform stability and security continues to increase

The first version of the Compact Framework was released in the early 2003. Adoption of the Compact Framework has steadily increased to the point where there are now over 10 million devices that ship with the Compact Framework in ROM, over 200,000 Compact Framework developers and over 600,000 downloads of version 1.0 Service Packs. Broad customer adoption such as this has enabled the Compact Framework team to gather large amounts of data about the overall stability of the product. Armed with this data, the Compact Framework team has been able to rapidly increase the maturity of the platform by fixing defects reported by customers.

In addition, the team now uses several automated tools to highlight areas of the code that may be vulnerable to security attacks. In addressing these issues, the Compact Framework team has reduced the likelihood that the applications it runs will be susceptible to known security attacks.

A Word about Application Compatibility

One of the biggest concerns an organization typically has when considering an upgrade to a new version of a platform is the level of compatibility that platform provides with previous versions. Compatibility is of critical importance to a broadly adopted platform such as the .Net Compact Framework. Without the ability to run applications built with earlier versions, a platform’s momentum slows quickly and its long term viability is all but eliminated.

To ensure the continued success of the Compact Framework, the product team has built an in-house compatibility lab to ensure that existing applications continue to run on new versions of the platform. Before shipping version 2.0, the product team tested over 650 commercial version 1.0 applications to make sure that compatibility issues were discovered and addressed to the greatest extent possible. When incompatibilities were found, changes were made to the Compact Framework such that existing applications continued to work as they always did.

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.