Зачем JIT, если у нас есть NGEN

• потому что многие приложения не «установлены» в этом смысле и не используют структуры, которые требуются NGEN; это просто файлы на запоминающем устройстве (или просто в памяти, если загружаются из внешнего источника)
• потому что NGEN привязан к оборудованию, а оборудование может изменяться в течение срока службы машины.
• потому что сам JIT можно обновлять отдельно для ваших приложений, исправляя ошибки и повышая производительность
• потому что приложения используют такие вещи, как плагины и точки расширения; все может быть недоступно, когда вы NGEN
• потому что многие приложения используют метапрограммирование для генерации оптимизированного кода для себя во время выполнения на основе точных условий (которые могут быть внешними данными, неизвестными до тех пор, пока они не будут фактически вызваны во время выполнения — как ORM сопоставляют столбцы базы данных с объектами , Например)
• потому что во многих случаях это не стоит затрат на NGEN — это не улучшит ситуацию.

Когда NGEN или AOT подходят: отлично, сделайте это. Но это не волшебная палочка, которая решает все проблемы.

Еще один вопрос, как JIT будет компилировать IL-код, если он уже NGENed?

Предполагая, что все предварительные условия для идеального совпадения образа NGEN выполнены, JIT не нужно будет задействовать.

В этом сообщении есть некоторые объяснения, почему NGEN может быть не таким привлекательным, как кажется.

И здесь есть очень старые рекомендации от Microsoft, когда использовать NGEN.

Еще один вопрос, как JIT будет компилировать IL-код, если он уже NGENed?

Если среда выполнения решит, что требуется перекомпиляция, она полностью проигнорирует образ NGENed.