Настройка приложения C # для максимальной производительности сборки

Question

Так что мы очень довольны нашей программой. Это быстрый и стабильный режим отладки, и пока эта версия доступна пользователям. Теперь мы хотим получить бесплатную поддержку от сборки релиза.

Я сейчас скомпилировал проект для выпуска с оптимизацией кода: вкл. У меня есть константа TRACE: выкл. Дополнительно -> Вывод -> Отладочная информация -> Нет.

Помимо эффективного кодирования, системной архитектуры и т. Д., Каковы оптимальные настройки Visual Studio для настройки приложения C # на максимальную производительность?

Насколько я знаю, JITter оптимизирует компиляцию IL по умолчанию в сборках выпуска. Оптимизация кода (: On) касается компилятора и того, как он работает со вставками и т. Д.

Это или есть еще? Выключение константы TRACE - ошибка? (наше приложение отправляет нам по почте дерево стека, если что-то серьезное должно пойти не так, я не уверен, что здесь TRACE))

Answer 1

Это рекомендуемые настройки, которые я бы выбрал для сборки выпуска, все эти настройки находятся на вкладке «Сборка» свойств проекта:

• Снимите отметку «Определить постоянную отладки»
• Снимите отметку «Определить постоянную TRACE»
• Чек"Оптимизировать код"
• В диалоговом окне «Дополнительно ...» установите для «Отладочная информация:» значение «только для pdb»

Вы можете также хотите рассмотреть возможность использования ngen для ускорения времени запуска приложения. Этот процесс должен выполняться на компьютере конечного пользователя (как правило, как часть процесса установки), однако, как правило, только улучшит производительность приложения при первом запуске *. Я бы посоветовал использовать ngen, только если у вас есть особые опасения по поводу времени холодной загрузки вашего приложения.

Что на самом деле делают эти настройки?

Константы отладки и TRACE

Константы DEBUG и TRACE влияют на любой код, включенный в условные директивы , например: (при необходимости замените DEBUG на TRACE)

#if DEBUG
// Anything here will not appear in the end output unless the DEBUG constant is defined
#endif

Это также влияет на любые вызовы, сделанные к методам, отмеченным Условным атрибутом , таким как Debug.Write и Trace.Write:

// The following call will not appear in the end output unless the DEBUG constant is defined
Debug.WriteLine("Test");

Вы можете сами проверить оба из них, используя что-то вроде IL Spy .

Обратите внимание, что эти константы не имеют другого эффекта, например, JITer не ведет себя иначе, если определена константа DEBUG. Вы, вероятно, обнаружите, что они оказывают незначительное влияние в вашем приложении, если вы не используете здоровенные условные директивы.

Оптимизировать код

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

Следующий вопрос описывает, что делает этот параметр более подробно:

• Преимущества опции «Оптимизировать код» в сборке Visual Studio

Отладочная информация

Параметр pdb-only указывает компилятору поместить всю отладочную информацию в отдельный файл .pdb (база данных программы). Что касается конечной сборки, это точно так же, как настройка none, в которой сборка не затрагивается, однако, если вы используете настройку pdb-only (сверх настройки none), символы по крайней мере доступны, если Вы хотите (вам не нужно распространять их, если вы не хотите). Это может быть очень полезно, например, при отладке аварийных дампов.

Обратите внимание, что вы не можете "вернуться" и заново сгенерировать символы для существующей сборки - если вы потеряли .pdb для сборки (или решили не создавать ее в первую очередь), это в значительной степени Потеряно навсегда! Заботьтесь об этом (особенно для сборок, которые вы выпускаете «в дикую природу»).

Единственное реальное отличие, которое вы увидите здесь, - это размер выходной сборки - это может повлиять на время загрузки и объем памяти, но в конечном итоге этот параметр, вероятно, не будет иметь особенно заметного эффекта.

---

(*) при условии, что пользователь использует большинство / все функции приложения при первом его запуске - процесс JITing выполняется как вызываемый метод. Читайте о JITting / ngen для более подробной информации.

Answer 2

Подход, который я видел в нескольких программах (на ум приходят Paint.NET и Adobe Acrobat Reader), заключается в том, что при установке они используют ngen в своих управляемых сборках. Это обеспечивает небольшое увеличение времени выполнения, но время запуска уменьшается, так как JIT больше не нужно использовать.

Это может использоваться вместе с другими оптимизациями, которые вы делаете.

(Обратите внимание, что вы не можете запустить ngen как часть процесса сборки, поскольку он учитывает особенности оборудования, на котором он в данный момент работает)

Answer 3

Не намного, вы можете сделать это через VS, что даст вам достаточно существенный или заметный прирост производительности. Вам будет лучше потратить время на запуск программы через профилировщик и посмотреть, где вы можете точно настроить код. Потратьте немного времени на рефакторинг некоторого кода, в частности, касающегося ввода-вывода, дБ и использования параллельного / потокового и кэширования, когда это возможно, может дать вам гораздо лучший результат

Answer 4

Производительность между выпуском и отладкой обычно едва заметна.

Большинство программ на C # проводят большую часть своего времени в сборках .net, которые уже оптимизированы.