[RESOLVED] NGen

Does anyone use NGen to generate native images of their assemblies? I have always been quite puzzled by NGen because all MS articles that describe it basically make it sound like it has quite a few advantages compared to the disadvantages. Basically it looks like it will improve the speed of your application in most cases but if that is the case then why doesnt everyone use it all the time? ...or maybe they do and its just me that has not really used it much.

Just wondered what other people's thoughts/experiences are?


Oh and for anyone not sure what I am talking about:

Quote:

---

Native Image Generator (Ngen.exe)

The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. 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 using the just-in-time (JIT) compiler to compile the original assembly.

---

Never even heard of it!

Get your head out of the sand Mcdonnell!

I am also Curious to learn about. I remember Jhon posted some where else. Let me dig it

Quote:

---

Originally Posted by DeanMc

Never even heard of it!

---

Me either, but Google has.

NGen

It seems to know everything that google, I looked it up but I wont pretend I know what it does.

lol looks like its not just me that doesnt use it then...

Shall I assume then that not many people use this?

I've never seen this either.

Me either.
What's a native image of an assembly anyways?

I think it means like any other non .net EXE basically - rather than it containing IL code for the JIT compiler to compile at runtime, it would just contain machine code like an EXE that has been built in unmanaged C++ or something would. I'm just guessing though so dont take my word for it!

EDIT: from a quick google search

Quote:

---

NGEN is the Native Image Generator and it's used to create platform specific "native code" versions of your systems.

---

and

Quote:

---

Simply put, ngen (Native Image Generator) is a tool that comes with .NET v1.x and higher and is used to create a "native image" for a given assembly. As you probably know, the CLR executes IL-code which cannot be understood by a processor. Instead, it needs to be translated into native code which can run on the computer's physical processor(s). The CLR execution engine contains a so-called JIT (just in time) compiler to accomplish this IL-to-native-code translation at runtime. However, this compiled (native) code isn't stored, it's just kept in memory during the containing process' lifetime. When the application is restarted, the JIT compiler comes into play again to compile the same code to native code again. The ngen tool lets you create a native image and store it physically on disk in a "native image cache" (aka NGen cache)

---

As I recall reading, nGens speed up the load time the FIRST time a user runs the app. After the first time the app is run the framework caches a copy of the native code so it doesnt have to jit'ter it again (as long as the assembly hasnt changed). I've used it on websites so that it speeds up the response the first time a page gets "hit", I dont think I have ever even considered using on desktop stuff. Oddly even after you nGen your assembly you still have to distribute the msil version of your assembly, so its worthless as code protection(stopping reflection)

I think its actually the exact opposite of that lol it doesnt make much different to 'cold' startup times but make repeated startup faster.

Quote:

---

After the first time the app is run the framework caches a copy of the native code so it doesnt have to jit'ter it again

---

I thought that was the purpose of NGen - to stop the framework having to JIT your code again as it would normally do.

From MSDN:

Quote:

---

As you know, the just-in-time (JIT) compiler is used for compiling the Microsoft intermediate language (MSIL) code in a .NET assembly into native code for the local machine immediately before the code is executed. This is temporary code; it is created and stored in the running processes's memory space, which is reclaimed by the OS when the process dies. Thus, it will be regenerated each time a new process needs it.

---

and about the startup speed:

Quote:

---

Measurements in the CLR performance labs have shown significant startup time improvements when using native images instead of JIT compilation. These gains don't necessarily apply to all applications, though, and are usually limited to the warm startup case. Warm startup occurs when a managed program has been run previously and hence much of the code for the runtime and the native images has already been loaded from disk into memory. Cold startup—launching a managed application for the first time immediately after starting the computer—does not benefit as much from NGen because costly disk accesses dominate the startup time.

---

http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx

I was incorrect. The jit'tered native image cache only lasts as long as the process is kept alive. *Shuts up now*

Quote:

---

Originally Posted by MSDN

Determining When to Use Native Images

Native images can provide performance improvements in two areas: improved memory use and reduced startup time.

Note

Performance of native images depends on a number of factors that make analysis difficult, such as code and data access patterns, how many calls are made across module boundaries, and how many dependencies have already been loaded by other applications. The only way to determine whether native images benefit your application is by careful performance measurements in your key deployment scenarios.

Improved Memory Use

Native images can significantly improve memory use when code is shared between processes. Native images are Windows PE files, so a single copy of a .dll file can be shared by multiple processes; by contrast, native code produced by the JIT compiler is stored in private memory and cannot be shared.

Applications that are run under terminal services can also benefit from shared code pages.

In addition, not loading the JIT compiler saves a fixed amount of memory for each application instance.

Faster Application Startup

Precompiling assemblies with Ngen.exe can improve the startup time for some applications. In general, gains can be made when applications share component assemblies because after the first application has been started the shared components are already loaded for subsequent applications. Cold startup, in which all the assemblies in an application must be loaded from the hard disk, does not benefit as much from native images because the hard disk access time predominates.

Hard binding can affect startup time, because all images that are hard bound to the main application assembly must be loaded at the same time.

Note

If you have shared components that are strong-named, place them in the global assembly cache. The loader performs extra validation on strong-named assemblies that are not in the global assembly cache, effectively eliminating any improvement in startup time gained by using native images.

---

I've never been in a position where I thought I'd benefit significantly from using NGen.

So basically from the replies here it looks like no one really uses it then... I guess that answers my question :)