Questions and Confusion
Before the new year holiday I had a good friend of mine ask me a question I must admit I didn't fully understand. The main point of his question was centered around the lifecycle of the MSIL code once its compiled into binary. Did the compiled copy get created per application session? Is it stored in a cache? When and how does it expire?
The main confusion I had was context, is he talking about Winform or ASP.NET? I assumed Winform as I know my friend understands ASP.NET very well and I was right. After talking to him he explained that his main concern was the performance of .NET code vs native C++ code. He assumed that the difference would be minimal if the code can be pre-compiled as the JIT would be one of the biggest performance hit in this kind of scenario.
To be honest I didn't know the answer to his question, but doing some research I believe I have come up with the answer.
NGEN Utility
NGEN is a utility that comes with the .NET Framework and can be located at paths such as the one below for the 2.0 edition:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\NGen.exe
For more information on how NGEN works I recommend this article from MSDN magazine May 2006 issue: CLR INSIDE OUT: The Performance Benefits of NGen. This article talks in detail on how to use NGEN to gain performance benefits but here is the general idea.
The basic idea behind JIT for .NET in a scenario were NGEN pre-compile is not used is as follows
- You call for the execution of a .NET managed EXE or DLL
- The JIT (Just-in-time compiler) kicks in and compiles it inside of the windows directory (best guess of the location, more on this later) under some funky name
- As long as you keep running your program, it stays in the Native Image Cache (NIC)
- When your program terminates the Native Image is cleaned out of the NIC. Meaning that next time you run your program, it will need to recompile again
When using NGEN to install your application through the "NGEN INSTALL c:\yourapppath\yourapp.exe" command the application and its dependencies are pre-compiled into the %WINDIR%\assembly directory. This save startup time and avoides the constant JIT compilation on every start.
The downside to using NGEN (as noted in various articles and blogs) is that the disk footprint of your application becomes larger, since the compiled Native Image is larger then the MSIL code. With today's hard drives though I don't see how this would be an issue in most circumstances.
To me based on this information using NGEN seems like a smart move that can benefit any application but especially large ones or those that spin-up and spin-down often.
Unfortunately I do not have time right now to try all of this for myself so all my information should be taken with a grain of salt.
Pending Questions about NGEN
I also have a few important questions pending. I will attempt to answer them at a later point as time allows:
- I cant seem to find where the JIT Native Images are stored when not using NGEN. I'm guessing the location is %WINDIR%\. This assumption is based on the following blog post talking of issues with JIT, Windows Directory and permissions on Citrix Servers: .Net Framework Applications Writing to the Windows Root Directory
- I don't know when using NGEN starts making sense. Is there a natural point at which NGEN becomes a large performance benefit? JIT must be very fast for most modern applications?
- Is NGEN automatically called by the installer when you create an MSI form Visual Studio or 3rd party tools like InstallShield? Perhaps NGE is already used a lot more often then I realize
- Is .NET smart enough to recompile the Native Image in the Cache automatically if you update the EXE/DLL but don't run NGEN UPDATE command? If this is not the case then I see a major downside to using the pre-compile for applications that are updated manually
If anyone has any insights into these questions please feel free to post a comment reply to this blog entry, id love to hear from you.
Additional Resources
While doing my research I found a few other links worth mentioning:
- Improving WPF applications startup time: This post by the WPF Performance PM (no name given in Blog) talks about various points that can hurt WPF performance and touches on NGEN. Interesting article worth reading
- NGEN in MSDN Magazine: Another great NGEN article
- Windows Forms Performance Tips in MSDN Magazine: Talks about various way to improve the performance of your windows applications
Underlying Concern: Performance of the CLR
What drives this whole topic more then any other issue is the concept of performance. When comparing .NET C# vs lets say C++ native code people can definitely point fingers and claim various performance benefits in doing thing closer to the platform with C++. Fortunately anything gained by native code is in most situations outweighed by the productivity gained when using an easy to develop in managed environment as provided by VS 2005/2008 and .NET C# or VB.NET.
There is a time to build super efficient code and there is a time to deliver solutions quickly. Make the choices that make sense for your project and don't look back.
Today a good friend asked me "I downloaded the .NET 2.0 framework and this application is still asking me for the .NET 1.1 framework, doesn't 2.0 include it?"
