Doubt in NGEN and CLR
-
Hi, I need some basic low level details of what happens when you ngen a .NET assembly. Lets take a c++ code which when compiled creates a binary executable. On executing this binary, the OS allocates memory for the process and executes it. No concept of runtime or CLR here. Everything is present in the binary. I read the MSDN and understand that .NGEN creates a native image of the code and avoids JIT compilation while execution by the CLR. Hence, at the end, I understand that the ngen creates binary code for specific processor. If the native code (binary) is ready then why cant the OS take care of executing it and why the .NET runtime has to do the execution? What does the CLR do then for a ngended assembly ? I seem to get confused with this concept.Please clarify. Thanks, Mani
-
Hi, I need some basic low level details of what happens when you ngen a .NET assembly. Lets take a c++ code which when compiled creates a binary executable. On executing this binary, the OS allocates memory for the process and executes it. No concept of runtime or CLR here. Everything is present in the binary. I read the MSDN and understand that .NGEN creates a native image of the code and avoids JIT compilation while execution by the CLR. Hence, at the end, I understand that the ngen creates binary code for specific processor. If the native code (binary) is ready then why cant the OS take care of executing it and why the .NET runtime has to do the execution? What does the CLR do then for a ngended assembly ? I seem to get confused with this concept.Please clarify. Thanks, Mani
When NGen compiles your IL into a native assembly is still uses the CLR and the .NET framework class libraries. Also there would be a problem with updates to the .NET framework. For example if there was a security hole in the console.writeline method and you installed a patch for it then all the apps that use that method would not be updated and would require re-Ngening. Here are some pros and cons to NGening. PROS: Improved application startup time: Since there is no JIT compilation. Reducing the apps working set: Best if the app is going to be loaded into mutliple AppDomain or processes at the same time. Although the working set will still be less if not being used in multiple appdomains/processes. CONS: NGen files can get out of sync: updates to the hardware or .NET Framework will cause this. Load-time performance hit: NGen files have the memory address references statically calculated. If for some reason it cannot be loaded at its preferred base address then it will require rebasing (Windows will have to relocate the file and fix up memory address references.) Slower runtime performance: Ngen cannot make as many assumptions about the hardware and OS as the JIT can. The JIT can perform many more optimizations than NGen
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
-
When NGen compiles your IL into a native assembly is still uses the CLR and the .NET framework class libraries. Also there would be a problem with updates to the .NET framework. For example if there was a security hole in the console.writeline method and you installed a patch for it then all the apps that use that method would not be updated and would require re-Ngening. Here are some pros and cons to NGening. PROS: Improved application startup time: Since there is no JIT compilation. Reducing the apps working set: Best if the app is going to be loaded into mutliple AppDomain or processes at the same time. Although the working set will still be less if not being used in multiple appdomains/processes. CONS: NGen files can get out of sync: updates to the hardware or .NET Framework will cause this. Load-time performance hit: NGen files have the memory address references statically calculated. If for some reason it cannot be loaded at its preferred base address then it will require rebasing (Windows will have to relocate the file and fix up memory address references.) Slower runtime performance: Ngen cannot make as many assumptions about the hardware and OS as the JIT can. The JIT can perform many more optimizations than NGen
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
Hi,
Captain See SharpSlower runtime performance: Ngen cannot make as many assumptions about the hardware and OS as the JIT can. The JIT can perform many more optimizations than NGen
Is this always true, also when NGening the assemblies directly on the target machine? Robert
-
Hi,
Captain See SharpSlower runtime performance: Ngen cannot make as many assumptions about the hardware and OS as the JIT can. The JIT can perform many more optimizations than NGen
Is this always true, also when NGening the assemblies directly on the target machine? Robert
So, if I have a stand alone .NET application in a system, Ngening those .NET assemblies is recommended or not. Please clarify.
-
Hi,
Captain See SharpSlower runtime performance: Ngen cannot make as many assumptions about the hardware and OS as the JIT can. The JIT can perform many more optimizations than NGen
Is this always true, also when NGening the assemblies directly on the target machine? Robert
-
So, if I have a stand alone .NET application in a system, Ngening those .NET assemblies is recommended or not. Please clarify.
He is Cool wrote:
So, if I have a stand alone .NET application in a system, Ngening those .NET assemblies is recommended or not.
You would definitly not NGen an assembly if it is a server application as the performace hit would only be on the first request. In general you should not NGen an assembly unless you have a very good reason to and in most cases there is no reason to. One reason to NGen an assembly would be to reduce the working set and improve startup performance but usually the overall runtime performance of your app would not be as good as if it were JITed.
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██