Ngen or not? The rules haven't changed very much since 2004

I still get questions that amount to "should I ngen my <something>" from time to time and the best answer I can give is still "it depends."  I wrote this article many years ago, and I'd say it's still pretty accurate: https://blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx

Essentially the situation is this: if you ngen your IL then of course the jit will not have to run but you will have to do more I/O because the compiled code is bigger than the IL.  If that I/O is likely to be cached because either:

1. The code is going to be loaded "a goodly amount of time" after ice cold startup and it's commonly used so superfetch is likely to fetch it, or
2. The code is in a library shared by many programs and so only one of those programs at most will have to actually read it at full cost

then it's likely that ngen will help you overall.

If that's not the case then ngen isn't likely to help you.  But really you need to measure for yourself.

Remember also that the code generation for ngen'd binaries is going to tend to optimize for maximum sharability which may come at a (typically small) cost in raw speed so that's a factor as well.

The most common framework DLLs, like mscorlib, system.dll and friends, tend to be get the most benefits from ngen.  Single-use application libraries and executables tend to get the least benefit.

It's really hard to say more than that with any kind of precision.

Comments

• Anonymous
  February 01, 2012
  I'm missing the point of this post... If nothing has changed in the past 8 years, why writing about it?

• Anonymous
  February 02, 2012
  Sometimes it's worth it to say, "no really the old advice is still good." That's all.  And not everyone was around to see the old article.

• Anonymous
  February 05, 2012
  I actually wasn't around for the old article so there - thank you for this blog post!