Got a need for speed? .NET apps start faster.

Got a need for speed? .NET apps start faster.

Rate This
  • Comments 13

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.

Leave a Comment
  • Please add 6 and 2 and type the answer here:
  • Post
  • NGEN is not enough. I want full AOT compilation with code optimizations (e.g. /O3, auto-vectorization, SSEX, etc.).

  • Ok, so now that we have this ".NET apps start faster" we would like to have ".NET apps runs faster", which is much more appealing! ;)

  • all i really want from .NET is the ability to compile the framework into my code so I dont have to worry if the end user has that framework installed or the ability to install the framework (no admin, no internet etc)

  • @Daniel: I want the same, but in the JIT. If you have no hard start-up time requirements, a good JIT can outperform an AOT compiler by using profiling data.

    Of course desktop apps do have start-up time requirements, and that's where things like NGEN come in, but for continuously running services with dynamic workloads (server-side) an adaptive JIT is more interesting. Of course there are usually timing requirements for handling requests that make things difficult...

    Also, *full* AOT compilation would mean on the developer's machine, and you probably don't want that (since you can't tune to the end user's machine). NGEN is a pain in the ass for framework servicing, but that's only because there are so many assemblies to NGEN at once. Having to do NGEN once during install isn't a big deal for regular applications.

    Arguably, if you *really* care about performance (as in, big number crunching solutions), .NET is probably not your platform of choice anyway. The C/C++/Fortran folks have a 20 year head start on optimization experience. The languages are not necessarily better suited to optimization, but the compilers are. On the sunny side, it means .NET has plenty of room to grow and it's already quite usable.

    @Harold: you can target the minimum .NET version that's installed with the OSes you have to support (Vista comes with 3.0, 7 with 3.5 and 8 with 4.5 -- if you want to be really safe use 2.0). If you still have to support XP, then yeah, you're screwed. But you're screwed then anyway, regardless of .NET.

    It's safe to say .NET will never get the ability to statically link framework code -- it was never a scenario and retrofitting it would have massive costs, for comparatively little gain.

  • I'd love to see this AOT tool/service make it into the XBox One along with .Net itself (visualstudio.uservoice.com/.../4233646-allow-net-games-on-xbox-one)

  • I really like these posts ... I know it takes time out of your busy schedules BUT more of these posts with the public will go such a long way! :)

    Keep them coming plz

  • AOT is hard, and may be impossible in certain situations, but deterministic garbage collection and/or lower level memory control would go a long way to making C# more competitive in the mobile space.

  • I really like this article, Microsoft has made tremendous effort in improving speed with NGEN or it could be multi-core JIT or whether it's thread wrappers or Windows RT in windows 8, i was just wondering why microsoft never thought of directly targeting binaries as an option in the .NET platform targets and embed some of the CLR ability in the OS itself as microsoft vision to bring all its application on .NET platform.....?

  • Good post !!!

  • hmm so why is opening metro app insanely slow?

  • its a good information..........

    please can you post some useful information like this....

    thank you to give a great thing............

  • Thanks and very useful for me

  • It appears that .NET + NGEN = "regular" compiled/binary code.  So why are we forced to make our client's hardware work harder for little gains.  Is that not what architecture-specific Run Time Libraries are for?

Page 1 of 1 (13 items)