Surupa Biswas: CLR 4 - Resilient NGen with Targeted Patching

Play Surupa Biswas: CLR 4 - Resilient NGen with Targeted Patching
Sign in to queue


Surupa Biswas is a Program Manager on the CLR team working on NGen, CLR's Native Image Generator. The Native Image Generator (ngen.exe) creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly.

What happens to current NGen images when you update the .NET Framework or CLR by installing a patch or new version of the framework/CLR? Do you have to NGen everything all over again? Well, yes, today you do. Today, NGen images are rigid. But this conversation is about tomorrow, beginning with CLR 4. What do you think the answer is in the future context?

Tune in. Learn about what Surupa and team will be delivering in CLR 4 to enable resilient NGen via targeted patching. This all adds up to enabling framework and CLR patching/updating without requiring the regeneration of native images already stored in the local native image cache. How does this work, exactly? What are the implications of image resiliency on the future of patching?


CLR 4, NGen, Servicing



Download this episode

The Discussion

  • User profile image

    Awsome work, Surupa. Thanks for all your hard work on this, and to the rest of the CLR team. Can't wait for all these new features on 4.0!!!

    Also, very cool, to have something as intricate as a conversation about NI versioning be articulated as clearly and concisely as it was.

    Charles, book Surupa for a WM_IN show soon! Smiley


  • User profile image

    I'm really glad to see some serious work has been done in the direction of making patching the .NET Framework a lot less intrusive.  A lot of IT folks get really grumbly when it's time to patch the framework, because the NGEN process will run for 10+ minutes, usually after a reboot, and quite often when the user is trying to get their day started.  

    I also have to say, Ms. Biswas is a really engaging and interesting person to listen to.  It's always a big bonus when you can not only show your passion for your work, but explain it in a very clear way without a lot of umm'ing and ahh'ing.  

  • User profile image

    cool stuff Smiley ngen has always been kind of a mystery to me Smiley but the ngen code isnt diffrent from the jitted code right? is the only win in start up/load perf? [not trying to devaule that though, in esp, its important] Are there other benefits to ngening?

  • User profile image
    Surupa Biswas

    An NGen image contains code generated by the JIT compiler as well as data structures that the runtime generates (both are similar to what would be created at application runtime if the NGen image didn't exist). There are some differences in the code generated ahead of time vs. at runtime, but they're mostly minor (examples include generated code for accessing statics - at pre-compilation time we assume the module is going to be loaded as domain-neutral, the cross-module inlining rules are different (NGen rules are more conservative to allow for targeted patching), etc.). NGen enables sharing of code and runtime data structures across processes, so it typically improves both startup time (especially warm startup) and working set.

    Background information about NGen can be found in this article: Improvements we're making in CLR 4 are outlined here: and those made in 3.5 SP1 here:

  • User profile image

    What are the performance benefits of running JITed code against ngened code. Are the performance improvements significant? What are the criteria to use ngen native images instead of plain JITed code?

  • User profile image
    Surupa Biswas

    As with everything related to performance, you'll want to measure. Smiley For large client applications there is often a significant startup time & working set reduction (such as a 5x reduction in warm startup time) if an application is fully NGen-ed (i.e. NGen-ed application code running against NGen-ed Framework assemblies). Some of the criteria for deciding whether to NGen your application are described here:

Add Your 2 Cents