Некоторые предыдущие разработчики поставили некоторые сборки, которые были встроены в режим отладки в производство. Стоит ли перекомпилировать их в режиме выпуска и перераспределять их? Если бы только увеличение производительности на 1-2%, я бы просто оставил их там. С другой стороны, увеличение на 10-20% может изменить мой разум.
У меня был такой же вопрос примерно год назад, потому что у нас были серьезные проблемы с производительностью в производстве. Как мне объяснили, от поддержки MS Premier версии отладки включают в себя перехваты для отладки, что может привести к увеличению потребления памяти примерно на 10% в зависимости от того, что делает приложение.
Если у вас нет проблем, оставьте их в покое, но если у вас возникнут проблемы с потреблением памяти, переходите и перекомпилируйте/разворачивайте.
По моему опыту, я видел разницу в 30-40%. Это было с DotNetZip, библиотекой, которая выполняет шифрование, сжатие и небольшой файл ввода/вывода. Более 85% времени было потрачено на шифрование и сжатие, просто перемещая байты.
Если вы посмотрите на код IL, созданный для сборки Debug и Release, различия, как правило, довольно малы. Большинство различий заключаются в дополнительных командах nop в ключевых исходных точках для поддержки редактирования и продолжения и отладки исходной строки. Однако, когда среда выполнения .NET на самом деле делает JIT MSIL, сборка времени выполнения почти идентична. Самое большое различие возникает при подключении отладчика. Это не позволит JIT оптимизировать фактический текущий код.
Релиз версии часто намного меньше, потому что они просто не содержат столько кода. Могут быть исправления кода, окруженные операторами #if DEBUG, а также условные атрибуты, которые инструктируют компилятор опускать вызовы методам в режиме выпуска (например, Debug.WriteLine).
Я обнаружил, что методы Debug.WriteLine и Trace.WriteLine, оставленные в производственном коде и имеющие значительные последствия для производительности, даже если отладчик не подключен.
Стоит отметить, что код выпуска также удаляет некоторые препроцессоры, например:
#if DEBUG
...
#endif
Он также удаляет Debug.WriteLine, Debug.Assert и некоторые другие вещи в пространстве имен System.Diagnostics, которые могут быть полезны при тестировании, но бессмысленны в хорошо продуманном коде для сборки релиза.
Как правило, вы увидите преимущество, поскольку версия выпуска обычно скомпилирована с оптимизацией с использованием опции /optimize компилятора. Однако насколько большая разница будет зависеть от вашей конкретной сборки - вам нужно будет профилировать.
Я обнаружил, что разница в производительности увеличивается экспоненциально со сложностью кода - простое приложение может видеть только 5% -ную разницу, но я видел как 50% -ное замедление в сложных приложениях, особенно тех, которые связаны с большими структурами данных, такими как массивы или карты.
Конечно, существует вероятность того, что код отладки может быть немного другим, в зависимости от того, как вы настроены - посмотрите на утверждения, например.
Другим аргументом против использования отладочных сборников в производстве является то, что они потребляют гораздо больше памяти, так как требуется, чтобы загружались отладочные символы.