Many .Net programmers, including me, have complained on the slow startup of .Net applications. I know that this only occurs during the first execution of your application.
Why does this thing happen? It’s because of the JIT compiler. The JIT compiler tends to re-compile your .Net Assembly (.exe, .dll) to produce a native image of that assembly in your computer and store in a cache. As you might have already known, the assemblies that we are compiling in Visual Studio are not the native exe that is being produced in previous COM programming language (Visual Basic 6, Visual C++ 6.0, Delphi, etc.). These assemblies are being compiled to MSIL (Microsoft intermediate language) instead of its native counterpart. And as you might have guessed the MSIL couldn’t be executed directly by the computer and that’s where the JIT compiler comes in.
You might be asking, “why not just do it upon compiling my own program in Visual Studio?” To figure this out, we must first learn why this kind of approach was used. The JIT compiler is not really a bad thing. Actually, it makes your program run faster. Well, here’s the concept behind this. The problem on the past COM languages is that even though the executables that they are producing are in native code, these codes are never compatible with other processors. I mean, every processor has its own specifics to enable your program to run faster. And this is where the COM languages fall short. Their executables are only optimized on their development machine. Hence, deploying it to other machines would decrease its compatibility with the processor (except if the developer box is exactly the same with the client box which is unlikely to happen).
This is where the JIT compiler comes in. It recompiles your assembly to generate a native code that is fully compatible to your current CPU specifications. This makes your assembly run as fast as possible with your current hardware. But the problem is you’ll have to sacrifice your first execution because this is the time the JIT compiles your assembly. To make this clear, the JIT compiler recompiles your assembly when your assembly doesn’t have a native image in its cache. And the cache is being cleared every time you reboot your computer. So this means tat your program would be recompiled every time it is opened on a newly rebooted PC.
But there is a way to tweak your application to make it load much faster even if it is its first time to load. How? Just load your application so that the JIT compiler compiles your program at startup without showing the main GUI of your application. How to do this? Well, I have just learned about this new tool in the Microsoft Framework 2.0 SDK. The ngen.exe. This tool pre-compiles your application and generates the needed native image in the cache. With this, the JIT compiler would not execute and recompile your application when it loads for the first time. Here’s the syntax (it’s being executed in the commandline):
C:\ngen install ClientApp.exe
Note: The ngen.exe is located in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
So you must include it in your path or in my case I just created my own batch file that executes whenever Windows XP starts up. Or you can just use the
Visual Studio 2005 Command Prompt.
PATH=” C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727”
Ngen install C:\Program Files\MyProg\App1.exe
To learn more about ngen (Native Image Generator). Just look it up on MSDN or in the online MSDN help:
http://msdn2.microsoft.com