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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

Защита интеллектуальной собственности

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

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

Снижение производительности выполнения

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

также проверьте эту хорошую ссылку на эту тему - JIT Compilation and Performance - для NGen или Not to NGen?

Ответ 6

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

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

Заключение: я действительно рекомендую попробовать NGEN в вашем приложении!

Ответ 7

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

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

Ответ 8

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

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

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