Is .NET code post JIT being executed the same as native code

Question

.NET languages all compile to an intermediate language (MSIL).

As far as i know, during execution (and sometimes during other stages, which i am not fully knowledgeable about -- NGEN), code is being JITted (Compiled from MSIL into actual machine code).

I am wondering if after JITting the code there are performance "penalties" coming from the fact that the code is executing on the CLR, or whether the code behaves "the same" as any other native code?

Answer 1

There are a number of performance differences:

1. The free store for managed objects is implemented as a stack, not a heap (except for the Large Object Heap), and is lower overhead than the heap used by most native allocators. But then you pay for garbage collection and compaction later.

2. The JIT can inline some calls that an AOT compiler would have to leave virtual (i.e. calls into other assemblies). But the AOT compiler can spend more time looking for optimization opportunities.

3. Theoretically, the JIT can use advanced instructions present on the particular CPU running the code (e.g. AVX). Still waiting for a JIT that actually makes good use of them, though.

4. AOT compilers can use profiling data to control layout of code memory. JIT compilers almost always emit functions into memory in the order they were compiled.

Answer 2

The main performance penalty to JITed code is the time taken to compile the code when it's first run. That usually only exhibits itself as a (slightly, perhaps imperceptibly) longer startup time, though it can be a real hit if you're using it in a scenario like CGI where a new process is spawned to handle every request. Not that a CGI script written in .NET is a common use case, but it's the first example that popped into my head so I'm going to run with it.

NGen can improve your startup time by skipping the JIT step. The benefit is going to be biggest in a short-running program that gets run frequently, like a CGI script. (Or perhaps a Windows service that's set to start automatically is a better example, now that I think of it.) For programs that run infrequently, the executable is unlikely to be cached in memory so it's probably going to have to be loaded from the disk each time. The time it takes to read from disk is likely to dominate startup time and overwhelm NGen's benefits. And for programs that run for a long time, startup time probably isn't a significant performance characteristic.