Есть ли какой-либо (производительность) различие между Отладкой и Выпуском?

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

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

С тех пор существует нет #if DEBUG директива и т.п. в моем коде, я задаюсь вопросом, куда различие прибывает из.

Существует ли опция сборки проекта, которую я мог изменить? Или это имеет отношение к Коннектору MySql.NET, которая имела бы различные поведения в зависимости от режима сборки?

Править: Контроль галочек.

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

Сравнение:

Выпуск берет 20x, Отладка времени берет (среднее сравнение).

4,404,500/213,000 = 20

Теперь первая операция действительно дольше, но в целом, так является всеми другими временами для выпуска. Какая-либо идея?

РЕДАКТИРОВАНИЕ 2: Я добавил даже более широкие тесты, который вычисляет общее время. Для 50 загрузок учетной записи требуется в среднем 4 секунды в отладках, и 40 секунд в выпуске. Я начинаю становиться довольно отчаянным по этому - это - серьезная проблема производительности для моего приложения. У кого-либо есть предположение о том, как зафиксировать это?

5
задан Lazlo 9 April 2010 в 23:28
поделиться

3 ответа

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

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

1
ответ дан 13 December 2019 в 19:24
поделиться

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

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

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

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

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

8
ответ дан 13 December 2019 в 19:24
поделиться

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

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

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

2
ответ дан 13 December 2019 в 19:24
поделиться
Другие вопросы по тегам:

Похожие вопросы: