This post was written by Rich Lander, who works as a Program Manager on the .NET Framework. He worked on AutoNGEN for Windows 8.

This post focuses on how technologies such as Native Image Generator (NGEN), the .NET Framework Optimization Service (mscorsvw), AutoNGEN, and compilation in the cloud have improved the startup performance of .NET apps. (If you want to speed up mscorsvw on your machine, read Wondering why mscorsvw.exe has high CPU usage? You can speed it up.)

Use any apps? Pretty much all the time, right? You probably expect most apps, whether they check the weather or a stock price, to start up fast—you’re only willing to wait so long. If you expect to spend a longer time with an app or you pay a subscription for it, you will probably wait a little longer. We’ve been making apps faster for over 10 years now, on Windows and Windows Phone, to reduce your wait.

App performance comes down to the work that the computer, phone, or tablet needs to do in order to get the app up and running. Some of that work requires number crunching by the CPU and some of it involves opening relatively large files on the hard disk. It was pretty obvious to us, back in the early 2000s, that we could improve performance by making efficient use of various aspects of computer hardware. We did that with our Native Image Generator (NGEN) technology. This is what you see in Windows, with substantial updates in Windows 8 and 8.1.

Starting about five years ago, we saw that computers were getting smaller instead of bigger. They were also becoming more portable, and spending more time running on a battery than connected to the wall. Phones and tablets were part of that trend. We had to make our NGEN technology work on smaller devices. This is what you see in Windows Phone 8.

We’ve had plenty of customer feedback throughout the past decade asking us to make app launch faster, on desktops as well as phone and tablets. This post is a look back at the work that we’ve done for app launch over the last 10 years, to answer those requests.

Doing work ahead of time with NGEN

We saw the need for a key performance technology before we shipped .NET Framework 1. We invented a new technology called NGEN to meet those needs. It was included in our first release.

Initially, we saw two major challenges:

• Computers were doing a lot of repetitive work to run .NET apps.
• Computers were spending a lot more time reading .NET app files than necessary.

NGEN solves these by doing two things:

• Compiling .NET Framework libraries to machine code upon installation of the .NET Framework on a given computer.
• Smart re-ordering of the machine code so that computers can execute .NET apps faster, using less memory.

We focus our use of NGEN on the .NET Framework libraries, because they tend to provide much of the actual implementation code for apps. When you install the .NET Framework, NGEN compiles these libraries to machine code, just once, for all apps to use. Because of this, all apps benefit—and they benefit a lot. That said, app developers can use NGEN for their code, and many do. There is often a sizable benefit for bigger apps.

Less NGEN, but just the right amount of less, with AutoNGEN

NGEN provided major performance improvements, but not everyone was happy with compiling the .NET Framework on their machines. At first, there wasn’t much of a problem, but as the .NET Framework grew and became widely adopted, we had to make NGEN smarter.

We added a background service so that NGEN could more easily ensure that all the .NET apps on a given machine launched quickly. We called this service the .NET Framework Optimization Services, which was implemented in mscorsvw.exe. Since this service ran in the background, it wasn’t always clear to users why their machine was doing work, sometimes for minutes at a time. (See Wondering why mscorsvw.exe has high CPU usage? You can speed it up.)

In Windows 8, we added significantly new behavior to the service, which we called AutoNGEN. The AutoNGEN behavior is quite conservative. It will only NGEN .NET apps or .NET Framework libraries that are actually used on a given machine. If you do not use a given app or library, AutoNGEN will not spend time compiling it to native code. In addition, AutoNGEN will only do work while your machine is idle. It can stop its work in less than 2s, when you start to use your machine again. This new behavior was put into Windows 8 as a response to the feedback that we received about unnecessary NGEN processing.

In Windows 8.1, we took NGEN one step further. When the .NET Framework is serviced (typically by Windows Update), the NGEN service determines if there is any work for it to do, and there often is. Instead of requiring that work to be done on all machines around the world, we can do some of that work at Microsoft, on a single set of machines. Starting in Windows 8.1 Preview, we do some of the NGEN work as part of our servicing updates. That means that your machine has less work to do, and that important files like mscorlib.dll always have an NGEN image available, resulting in more consistent performance after servicing.

Moving NGEN to the cloud for Windows Phone

We really like this idea of doing more of the NGEN work at Microsoft instead of on user machines. Customers like cloud compilation, too, particularly for phones and tablets. If you’re using Windows Phone 8, you’re already benefiting from our cloud compiler solution. That solution isn’t exactly NGEN, but an updated .NET compiler technology (see “Much faster code with ‘Compiler in the Cloud’” in the .NET Framework for Windows Phone 8 blog post). That solution moves almost all the work to cloud servers. Only a very small amount of work is done on the device when you install an app.

The compile in the cloud solution works well because all apps are uploaded to a central store, like the Windows Phone Store. As a result, we can build centralized infrastructure to compile apps automatically, before they are deployed to user devices. This is an approach that we plan to repeat for platforms that have centrally managed app deployment. For clarity, Windows 8 and 8.1 Preview use the AutoNGEN technology.

Summary

It is important for .NET apps to launch quickly. We’ve been investing in the NGEN technology for over a decade now to make apps launch faster, and also to make the process of compiling .NET apps and libraries as seamless as possible. The move to portable PCs and devices required rethinking startup performance solutions to work within the tighter constraints of those devices. App stores and the cloud provide us with a new opportunity to perform compilation on your behalf without having to do any significant work on user machines.

We also have other solutions for making apps launch faster, such as multi-core JIT, async and threads, and we encourage you to read about those.

This post was intended to provide you with a look back at the work we’ve done for app launch, with ahead of time compiler technologies. It is a mid-point for us. We’ve still got lots of ideas, and we’re working to make bigger improvements going forward.