GAC может содержать не-ngen-код (он должен содержать его, а также собственные изображения при использовании ngen, поскольку ngened-изображения не содержат всех необходимых метаданных). Для Ngen'd кода требуется, чтобы dll была установлена в GAC для эффективного функционирования (технически вы можете сделать это без, но в результате проверки имени запускается полное чтение вашей dll в любом случае , что может сделать ваше время запуска хуже ).
До 3.5 sp1 компиляция ngen определенно незначительно отличалась от времени выполнения, см. в этой статье для некоторых подробностей. Я полагаю, что это все еще верно для 3.5SP1, так как эти проблемы трудно решить.
Поскольку ngen действительно дает вам два больших выигрыша, вам следует подумать о том, значимы ли оба варианта в вашем сценарии, чтобы оправдать сложность и стоимость, связанные с их использованием.
- Время запуска этих DLL значительно сокращено
- Чтобы получить действительно большой выигрыш, хотя все dll, загруженные при запуске, должны быть сгенерированы, чтобы избежать накладных расходов на загрузку самого jit)
- Собственные изображения могут совместно использовать пространство памяти для нескольких процессов.
- Довольно бессмысленно, если вы запускаете только один или два процесса.
Я предлагаю Эта статья, детализирующая некоторые изменения в 2.0 ngen , является хорошим чтением, она охватывает такие вещи, как жесткое связывание, что является большим улучшением, и ссылки на превосходную общую документацию по написанию эффективных управляемых код, хотя он страдал от ссылки rot, см. msdn Глава 5 , к которой он относится. (обратите внимание, что этот документ старый, но многие темы по-прежнему действительны)