Ответ 1

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

• Снимите флажок "Определить константу DEBUG"
• Снимите флажок "Определить константу TRACE"
• Отметьте "Опиксельный код"
• В диалоговом окне "Advanced..." установите "Debug Info:" на "pdb-only"

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

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

Константы DEBUG и 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.

Ответ 2

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

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

Ответ 3

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

Это можно использовать наряду с другими вашими оптимизациями.

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

Ответ 4

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