Can I avoid JIT in .net

Question

Say if my code is always going to be run on a particular processor and if I have this information during installation - is there any chance I can avoid JIT?

Answer 1

You don't have to avoid JIT if you have CPU information at installation.

If you compile your modules using the /platform:[x86/x64/IA64] switch, the compiler will include this information in the resulting PE file so that the CLR will JIT the code into the appropriate CPU native code and optimize the code for that CPU architecture.

You can use NGEN, yes but only if you want to improve the application's startup as a result of the reduced working set in the processes running not becuase you would have avoided JITting. And you need to actually compare the NGEN'd files' performance against that of the non-NGEN'd files' to make sure that the NGEN'd one is faster.

NGEN can't make as many assumptions about the execution environment as the JIT compiler can and therefore will produce unoptimized code.

For example: it adds indirections for static field access because the actual address of the static fields is known only at run time.

Answer 2

Use NGEN:

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...

For additional information on using Ngen.exe and the native image service, see Native Image Service...

Answer 3

NGEN is the obvious answer, but I would point out that JIT-ed code can be faster as it "knows" about things at runtime that NGEN can't. We use that fact to literally drop lines of code on the floor at runtime based on a setting in our .config files:

static readonly bool _EnableLogging = LoadFromConfigFile("EnableLogging");
if (_EnableLogging && log.IsDebugEnabled)
{
   //Do some logging
}

In this example NGEN must leave the if statement in the code because it has no idea what the value of the _EnableLogging field is. However, JIT does know the value for this run and if it's false then there's no way the if statement will ever be processed, and the JIT will literally omit the entire if statement from the machine code it generates, resulting in a smaller codebase and therefore a faster codebase.