Есть ли разница в производительности между Debug и Release?

Question

Я использую MySql Connector .NET для загрузки учетной записи и передачи ее клиенту. Эта операция довольно интенсивна, учитывая, что дочерние элементы учетной записи загружаются.

В режиме отладки для загрузки учетной записи требуется не более 1 секунды. Среднее будет 500 мс. В режиме деблокирования для загрузки аккаунта требуется от 1 до 4 секунд. Среднее будет 1500 мс.

Поскольку в моем коде нет директивы #if DEBUG или тому подобного, мне интересно, откуда эта разница.

Есть ли вариант построения проекта, который я мог бы изменить? Или это связано с MySql Connector .NET, который будет иметь разные типы поведения в зависимости от режима сборки?

EDIT: Мониторинг клещей.

Debug (Average: 213000 ticks) 
730000 
320000 
60000 
50000 
190000 
130000 
210000 
180000 
160000 
110000 
390000 
270000 
150000 
190000 
230000 
210000 
150000 
200000 
190000 
140000 

Release (Average: 4404500 ticks) 
12940000 
170000 
180000 
80000 
80000 
130000 
120000 
5060000 
5090000 
130000 
50000 
10430000 
25160000 
150000 
160000 
130000 
17620000 
10160000 
100000 
150000 

Сравнение:

Release занимает 20x время отладки принимает (среднее сравнение).

4.404.500/213.000 = 20

В настоящее время первая операция на самом деле больше, но в целом, так и все другие времена для освобождения. Любая идея?

EDIT 2: Я добавил еще более широкие тесты, которые вычисляют общее время. Для 50 учетных записей в debug требуется в среднем 4 секунды, а в релизе - 40 секунд. Я начинаю отчаянно беспокоиться об этом - это серьезная проблема производительности для моего приложения. Кто-нибудь может предположить, как это исправить?

Answer 1

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

Спасибо за вашу помощь!

Answer 2

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

В режиме деблокирования может не потребоваться немедленная загрузка сборки, которая требуется позже вашей операцией (из-за различных оптимизаций, выполняемых для версий релизов). Следовательно, в режиме отладки сборка может быть загружена до того, как вы начнете синхронизировать свою операцию, и в режиме освобождения, когда сборка может быть загружена после начала синхронизации вашей операции. Время загрузки сборки может быть значительным в зависимости от того, насколько велика сборка. Конечно, сборка должна быть загружена в обоих случаях, и ее нужно загружать только один раз, поэтому последующие запуски в режиме выпуска могут быть быстрее.

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

Обновление: Интересно, что тайминги в режиме выпуска сильно различаются по сравнению с теми, в режиме отладки (ЗППП DEV является 100x выше режим выпуска). На нижнем конце тайм-ауты режима освобождения сопоставимы с режимами отладки. Вы указываете в своем вопросе, что загрузка учетной записи является интенсивной из-за всех дочерних элементов, которые необходимо загрузить. Другим отличием может быть тот момент, когда среда выполнения решает выполнить сборку мусора. Чтобы проверить, вы можете попробовать выполнить System.GC.Collect() после каждой операции (вне вашего таймера) и посмотреть, не изменит ли это что-то.

Update: Если вы подозреваете, что может быть изменение в поведении по отношению к фиксации, вы можете рассмотреть вопрос об использовании Windows Performance Monitor для мониторинга различного .NET LocksAndThreads счетчики CLR для процесса вашего приложения (ов), а вы запускайте свои тесты в режимах отладки и выпуска. Возможно, вы не размещаете какой-либо замок где-то, а исполнение задерживается до тех пор, пока не истечет некоторый тайм-аут? Если это так, я ожидаю увидеть увеличение уровня конкуренции, сообщаемого счетчиками производительности. Я не уверен, почему это будет проблемой только для выпусков (если вы не используете отладчик при запуске отладочных сборников).

Answer 3

Все на вкладках «Сборка» и «Отладка» в настройках свойств приложения может изменяться в зависимости от конфигурации сборки. Некоторые из них относятся только к этапу компиляции и не влияют на производительность выполнения (разрешить небезопасный код, ошибки и предупреждения, обрабатывать предупреждения как ошибки и файл документации XML). Остальные могут изменить ситуацию.

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

Я бы особенно проверить Определение константы DEBUG, определение константы TRACE, условные символы компиляции, целевой платформы, оптимизация кода (на расширенном экране) Проверьте арифметического переполнения/опустошения, Сформировать сборку сериализации, Включить неуправляемую отладку кода, и включить процесс хостинга Visual Studio.