5

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

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Sesh
  • 5,993
  • 4
  • 30
  • 39

3 Answers3

13

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

gnat
  • 6,213
  • 108
  • 53
  • 73
Igal Serban
  • 10,558
  • 3
  • 35
  • 40
  • e.g. Paint.NET makes use of it. – Xn0vv3r Jan 15 '09 at 10:05
  • The OP asks about install-time JIT avoidance, for which NGEN is relevant. For those wondering though, NGEN is a per-machine, install-time thing, not something you can use at original build time, i.e. you can't distribute the output of NGEN. (Please correct me if I'm wrong.) – yoyo Jun 11 '14 at 18:03
11

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.

Walden Leverich
  • 4,416
  • 2
  • 21
  • 30
  • 2
    I know this answer is a bit old now, but I don't believe this is correct. `_EnableLogging` will only be known when the code is run. The JIT compiler is trying to compile IL code so it *can* run. It won't execute the code to work out if it's `true`/`false` and will therefore compile the `if` block as is. – dariom Nov 15 '10 at 08:05
  • 3
    Actually, the JIT does know, I just gave an incomplete example. The static readonly is a class-level variable so it's loaded at class creation, the if() is w/in a method so it's JIT'd later in life. I confimed that the code was dropped in the floor using windbg and stepping through the generated machine code when we did this. – Walden Leverich Nov 24 '10 at 23:32
  • 1
    +1 for the specific example. +1 to @dariom for raising a question that resulted in @WaldenL expanding on his answer. Very interesting topic. – J M Feb 12 '11 at 00:40
6

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.

Abel
  • 56,041
  • 24
  • 146
  • 247
Lonzo
  • 2,758
  • 4
  • 22
  • 27