Вы когда-нибудь использовали ngen.exe?

Question

Кто-нибудь здесь когда-либо использовал ngen? Куда? Зачем? Было ли улучшение производительности? когда и где имеет смысл его использовать?

Answer 1

Я не использую его изо дня в день, но он используется инструментами, которые хотят повысить производительность; например, Paint.NET использует NGEN во время установки (или, возможно, при первом использовании). Возможно (хотя я не знаю наверняка), что некоторые из инструментов MS также делают.

В основном, NGEN выполняет большую часть JIT для сборки спереди, так что при холодном запуске очень мало задержки. Конечно, при наиболее типичном использовании никогда не достигается 100% кода, поэтому в некоторых случаях это приводит к большой ненужной работе - но он не может сказать это заранее.

Недостатком, IMO, является то, что вам нужно использовать GAC для использования NGEN; Я стараюсь по возможности избегать GAC, чтобы я мог использовать развертывание robocopy (на серверах) и ClickOnce (для клиентов).

Answer 2

Да, я видел улучшения производительности. Мои измерения показали, что это улучшило производительность при запуске, если я также поместил свои сборки в GAC, так как все мои сборки имеют строгие имена. Если ваши сборки имеют строгие имена, NGen не будет иметь никакого значения без использования GAC. Причина этого заключается в том, что если у вас есть сборки со строгими именами, которых нет в GAC, то среда выполнения .NET проверяет, что ваша сборка со строгими именами не была подделана, загружая всю управляемую сборку с диска, чтобы можно было ее обойти одно из главных преимуществ NGen.

Это был не очень хороший вариант для моего приложения, поскольку мы полагаемся на общие сборки нашей компании (которые также носят строгие названия). Общие сборки используются многими продуктами, которые используют много разных версий, поэтому их размещение в GAC означало, что если одно из наших приложений не скажет «использовать конкретную версию» одной из общих сборок, оно загрузит версию GAC независимо от того, что версия была в исполняющей директории. Мы решили, что преимущества NGen не стоили рисков.

Answer 3

Ngen в основном сокращает время запуска приложения .NET и рабочего набора приложения. Но у этого есть некоторые недостатки (от CLR Via C # Джеффри Рихтера):

Нет защиты интеллектуальной собственности

NGen'd файлы могут выйти из синхронизации

Низкая производительность по времени загрузки (перебазирование / связывание)

Низкая производительность во время исполнения

В связи со всеми перечисленными проблемами вы должны быть очень осторожны при рассмотрении вопроса об использовании Ngen.exe. Для серверных приложений NGen.exe не имеет большого смысла, потому что только первый запрос клиента испытывает снижение производительности; будущие запросы клиентов выполняются на высокой скорости. В Кроме того, для большинства серверных приложений требуется только один экземпляр кода, поэтому пособие по рабочему набору.

Для клиентских приложений NGen.exe может иметь смысл улучшить время запуска или уменьшить рабочий набор, если сборка используется несколькими приложениями одновременно. Даже в случае в Если сборка не используется несколькими приложениями, NGen'ом сборка может улучшить рабочий набор. Более того, если NGen.exe используется для всех сборок клиентского приложения, CLR совсем не нужно загружать JIT-компилятор, что еще больше сокращает рабочий набор. Конечно, если только одна сборка не является NGen'd или если файл NGen'd сборки не может быть использован, JIT-компилятор загрузится, и рабочий набор приложения увеличится.

Answer 4

ngen в основном известен тем, что улучшает время запуска (исключая компиляцию JIT). Это может улучшить (за счет сокращения времени JIT) или снизить общую производительность приложения (поскольку некоторые JIT-оптимизации не будут доступны).

.NET Framework сама использует ngen для многих сборок после установки.

Answer 5

Я использовал его, но только для исследовательских целей. используйте его ТОЛЬКО, если вы уверены в архитектуре процессора вашей среды развертывания (она не изменится)

но позвольте мне сказать вам, что JIT-компиляция не так уж плоха, и если у вас есть развертывания в нескольких средах ЦП (например, клиентское приложение Windows, которое часто обновляется), то НЕ ИСПОЛЬЗУЙТЕ NGEN. Это потому, что действительный кэш Ngen зависит от многих атрибутов. если один из них не удался, ваша сборка снова возвращается к jit

JIT - явный победитель в таких случаях, так как он оптимизирует код на лету на основе архитектуры процессора, на которой он работает. (например, он может обнаружить, если есть больше чем 1 процессор)

и clr улучшается с каждым выпуском, так что вкратце придерживайтесь JIT, если только вы не уверены в своей среде развертывания - даже тогда прирост производительности вряд ли оправдан с помощью ngen.exe (вероятно, выигрыш составит несколько сотен мс) - imho - это не стоит усилий

также проверьте эту действительно хорошую ссылку на эту тему - Компиляция JIT и производительность - Для NGen или Не для NGen?

Answer 6

Да, я пробовал это с небольшим одним процессором, интенсивно использующим процессор, и с ngen это было немного медленнее!

Я несколько раз устанавливал и удалял образ ngen и запускал тест.

Я всегда получал следующие воспроизводимые времена +/- 0,1 с: 33,9 с без, 35,3 с

Answer 7

Как дополнение к комментарию Мехрдада Афшари о компиляции JIT. Если сериализовать класс с множеством свойств через XmlSerializer и в 64-битной системе SGEN, комбо NGEN имеет потенциально огромный (в нашем случае гигабайты и минуты) эффект.

Больше информации здесь: Запуск XmlSerializer ОГРОМНАЯ потеря производительности на 64-битных системах см. Особенно ответ Ника Мартышенко.

Answer 8

Да. Используется в приложении WPF для ускорения времени запуска. Время запуска увеличилось с 9 до 5 секунд. Читайте об этом в моем блоге :

Я недавно обнаружил, насколько велика NGEN для производительности. приложение, над которым я сейчас работаю, имеет уровень доступа к данным (DAL), который генерироваться. Схема базы данных довольно большая, и мы также генерируем некоторые данные (список значений) непосредственно в DAL. Результат: много классы с множеством полей и множеством методов. JIT часто показывал вверх при профилировании приложения, но после поиска при JIT-компиляции и NGEN я, хотя это не стоило того. Время установки, с управление моей главной заботой, заставило меня игнорировать знаки и сосредоточиться на добавив больше функциональности в приложение вместо. Когда мы изменились В архитектуре «Любой процессор», работающей на 64-битных машинах, дела пошли хуже: Мы испытали зависание в нашем приложении до 10 секунд на одно утверждение, с профилировщиком, показывающим только издержки JIT на Проблема зоны. NGEN решил проблему: заявление пошло от 10 секунд до 1 миллисекунды. Это заявление не было частью процедура запуска, так что мне не терпелось узнать, что NGEN'ing весь приложение может сделать во время запуска. Прошло от 8 секунд до 3,5 секунды.

Вывод: очень рекомендую попробовать NGEN в вашем приложении!