Производительность отладки и выпуска
Я столкнулся со следующим абзацем:
"Параметр" Отладка против выпуска "в IDE при компиляции кода в Visual Studio практически не влияет на производительность… сгенерированный код практически одинаков. Компилятор C# на самом деле не выполняет никакой оптимизации. Компилятор C# просто выплевывает IL… и во время выполнения все JITer выполняет всю оптимизацию. JITer имеет режим Debug/Release, и это сильно влияет на производительность. Но это не отменяет, запускаете ли вы конфигурацию Debug или Release вашего проекта, это отключает, подключен ли отладчик ".
Источник здесь, а подкаст здесь.
Может кто-нибудь направить меня к статье Microsoft, которая может доказать это?
Поиск "Отладка в сравнении с производительностью релиза" в большинстве случаев возвращает результаты: "Отладка сильно страдает от повышения производительности", "выпуск оптимизирован" и "не развертывать отладку в производстве".
12 ответов
Частично верно. В режиме отладки компилятор выдает отладочные символы для всех переменных и компилирует код как есть. В режиме релиза некоторые оптимизации включены:
- неиспользуемые переменные вообще не компилируются
- некоторые переменные цикла извлекаются из цикла компилятором, если они оказались инвариантами
- код, написанный под директивой #debug, не включен и т. д.
Остальное зависит от JIT.
Изменить: Полный список оптимизаций здесь любезно Eric Lippert
Там нет статьи, которая "доказывает" что-либо о вопросе производительности. Чтобы доказать утверждение о влиянии изменений на производительность, попробуйте оба варианта и протестируйте их в реалистичных, но контролируемых условиях.
Вы задаете вопрос о производительности, так что явно заботитесь о производительности. Если вы заботитесь о производительности, то правильное решение - установить некоторые цели производительности, а затем написать себе набор тестов, который будет отслеживать ваши успехи в достижении этих целей. Если у вас есть такой набор тестов, вы можете легко использовать его, чтобы проверить для себя истинность или ложность утверждений типа "сборка отладки медленнее".
И, кроме того, вы сможете получить значимые результаты. "Медленнее" не имеет смысла, потому что неясно, будет ли он на одну микросекунду медленнее или на двадцать минут медленнее. "На 10% медленнее в реальных условиях" более значимо.
Потратьте время, которое вы потратили бы на исследование этого вопроса в Интернете на создание устройства, которое ответит на вопрос. Таким образом, вы получите гораздо более точные результаты. Все, что вы читаете в Интернете, является лишь предположением о том, что может произойти. Приведите факты, которые вы собрали сами, а не догадки других людей о том, как может вести себя ваша программа.
Я не могу комментировать производительность, но совет "не развертывать отладку в производстве" по-прежнему сохраняется просто потому, что в больших продуктах отладочный код обычно делает несколько разных вещей по-разному. Во-первых, у вас могут быть активны переключатели отладки, а во-вторых, возможно, понадобятся дополнительные избыточные проверки работоспособности и выходные данные отладки, которые не входят в производственный код.
Из мсдн соц
Это не очень хорошо задокументировано, вот что я знаю. Компилятор испускает экземпляр System.Diagnostics.DebuggableAttribute. В отладочной версии свойство IsJitOptimizerEnabled имеет значение True, а в версии выпуска - False. Вы можете увидеть этот атрибут в манифесте сборки с ildasm.exe
JIT-компилятор использует этот атрибут для отключения оптимизаций, которые затрудняют отладку. Те, которые перемещают код как петли-инвариантный подъем. В некоторых случаях это может существенно повлиять на производительность. Хотя обычно не так.
Отображение точек останова на адреса выполнения является задачей отладчика. Он использует файл.pdb и информацию, сгенерированную JIT-компилятором, который предоставляет инструкцию IL для сопоставления адресов кода. Если бы вы написали свой собственный отладчик, вы бы использовали ICorDebugCode::GetILToNativeMapping().
В основном отладочное развертывание будет медленнее, поскольку оптимизация JIT-компилятора отключена.
Я недавно столкнулся с проблемой производительности. Полный список продуктов занимал слишком много времени, около 80 секунд. Я настроил БД, улучшил запросы и не было никакой разницы. Я решил создать TestProject и обнаружил, что тот же процесс был выполнен за 4 секунды. Затем я понял, что проект находится в режиме отладки, а тестовый проект - в режиме выпуска. Я переключил основной проект в режим выпуска, и полный список продуктов занял всего 4 секунды, чтобы отобразить все результаты.
Сводка: режим отладки намного медленнее, чем режим выполнения, поскольку он сохраняет информацию отладки. Вы должны всегда развертывать в режиме Relase. Вы все еще можете иметь отладочную информацию, если включите файлы.PDB. Таким образом, вы можете регистрировать ошибки с номерами строк, например.
То, что вы читаете, вполне допустимо. Выпуск обычно более скудный из-за оптимизации JIT, не включая отладочный код (#IF DEBUG или [Conditional("DEBUG")]), минимальную загрузку символов отладки и часто не учитываемые - это меньшая сборка, которая сократит время загрузки. Различная производительность более очевидна при запуске кода в VS из-за более обширной PDB и загруженных символов, но если вы запускаете ее независимо, различия в производительности могут быть менее заметными. Определенный код будет оптимизироваться лучше, чем другие, и он использует такую же оптимизирующую эвристику, как и в других языках.
У Скотта есть хорошее объяснение оптимизации встроенного метода здесь
В этой статье дается краткое объяснение, почему в среде ASP.NET они отличаются для параметров отладки и выпуска.
На сайте MSDN...
Конфигурации выпуска и отладки
Пока вы все еще работаете над своим проектом, вы, как правило, создаете свое приложение с использованием конфигурации отладки, поскольку эта конфигурация позволяет вам просматривать значение переменных и контролировать выполнение в отладчике. Вы также можете создавать и тестировать сборки в конфигурации выпуска, чтобы не допустить ошибок, которые проявляются только в одном типе сборки или в другом. В программировании на.NET Framework такие ошибки встречаются очень редко, но они могут возникать.
Когда вы будете готовы распространять свое приложение среди конечных пользователей, создайте сборку выпуска, которая будет намного меньше и будет обычно иметь гораздо лучшую производительность, чем соответствующая конфигурация отладки. Вы можете настроить конфигурацию сборки на панели "Сборка" дизайнера проектов или на панели инструментов "Сборка". Для получения дополнительной информации см. Конфигурации сборки.
Вы должны отметить одну вещь, касающуюся производительности и того, подключен ли отладчик, или что-то, что застало нас врасплох.
У нас был кусок кода, включающий много трудных циклов, который, казалось, занимал отладку вечно, но сам по себе работал довольно хорошо. Другими словами, нет клиентов или клиентов, у которых возникли проблемы, но когда мы отлаживали, казалось, что они работают как патока.
Виновником был Debug.WriteLine в одном из трудных циклов, которые выплевывают тысячи сообщений журнала, оставленных от сеанса отладки некоторое время назад. Кажется, что когда отладчик подключен и прослушивает такой вывод, возникают накладные расходы, которые замедляют работу программы. Для этого конкретного кода время выполнения было порядка 0,2-0,3 секунды, а при подключении отладчика - более 30 секунд.
Простое решение, однако, просто удалите отладочные сообщения, которые больше не нужны.
В значительной степени это зависит от того, привязано ли ваше приложение к вычислениям, и это не всегда легко определить, как в примере с Лассе. Если у меня есть малейший вопрос о том, что он делает, я делаю паузу несколько раз и проверяю стек. Если происходит что-то лишнее, что мне действительно не нужно, это сразу замечает.
Режимы отладки и выпуска имеют различия. Существует инструмент Fuzzlyn: это фаззер, который использует Roslyn для генерации случайных программ на C#. Он запускает эти программы в ядре.NET и гарантирует, что они дают одинаковые результаты при компиляции в режиме отладки и выпуска.
С помощью этого инструмента было обнаружено и зарегистрировано множество ошибок.
Я просто объясняю свой собственный опыт.
Я работаю в сфере здравоохранения над несколькими приложениями корпоративного уровня. Мы измерили производительность Debug VS Release (VS 2019 .NET 4.7). Большинство наших приложений основаны на веб-формах и C#.
Разница между отладкой и выпуском различных функций и страниц в нашем случае составила всего около секунды (фактически менее 1 секунды).
Наш бизнес действительно не заботится об этой разнице, но если бы я работал с приложением для обработки транзакций с рыночными акциями, тогда были важны даже миллисекунды, и именно здесь режим Release становится важным.
Отключите ведение журнала и отладку. Перед сборкой приложения для выпуска убедитесь, что вы отключили ведение журнала и отключили параметр отладки. Вы можете отключить ведение журнала, удалив вызовы методов журнала в исходных файлах. Вы можете отключить отладку, удалив атрибут android: debuggable из тега в файле манифеста или установив для атрибута android: debuggable значение false в файле манифеста. Также удалите все файлы журналов или файлы статических тестов, которые были созданы в вашем проекте.
https://developer.android.com/studio/publish/preparing
Как удалить все вызовы журнала отладки перед созданием релизной версии приложения для Android?
Разница между отладочными и релизными apks
Разработка, тестирование, приемка и производство
https://blog.chizobaogbonna.me/having-different-variants-debug-staging-release-of-your-app-on-a-single-device-2efdcaaf4950https://ajiethkumar.wordpress.com/2017/04 / 07 / it-environment-management / внутренняя сеть и периметр
https://www.onlinecomputertips.com/support-categories/networking/646-what-is-a-dmz
https://dev.to/aws-builders/jump-over-a-hurdle-of-working-with-amplify-backend-environment-c77
https://en.wikipedia.org/wiki/Development,_testing,_acceptance_and_productionhttps://oroinc.com/b2b-ecommerce/blog/testing-and-staging-environments-in-ecommerce-implementation/
https://medium.com/the-liberators/want-to-be-agile-drop-your-dtap-pipeline-7dcb496fe9e3
https://www.bmc.com/blogs/what-is-shift-left-shift-left-testing-explained/
https://blogs.vmware.com/management/2013/11/features-for-gotit- series-vcac-6-0-simpleify-application-deployments-through-any-environment.html 
https://enterprise.arcgis.com/en/server/10.3/administer/linux/arcgis-server-in-development-staging-and-production-environments.htm 
https://learn.timextender.com/courses/259790/lectures/4029947 https://humanitec.com/blog/kubernetes-environments-basics https://blogs.oracle.com/ openomics / использование-сайта-аварийного восстановления-для-разработки-часть-2 https://doc.oroinc.com/cloud/environments/ 
