Существуют ли риски для оптимизации кода на С#?

На панели настроек сборки VS2010 Pro есть CheckBox с меткой "оптимизировать код"... конечно, я хочу проверить это... но, будучи необычно осторожным, я спросил об этом моего брата, и он сказал, что он не установлен для отладки и что на С++ он может потенциально делать то, что может сломать или исправить код... но он не знает о С#.

Итак, мой вопрос: могу ли я установить этот флажок для своей сборки релиза, не беспокоясь о том, что он нарушает мой код? Во-вторых, если он может сломать код, когда и почему? Ссылки на объяснения приветствуются.

Ответ 1

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

Ответ 2

Оптимизация не должна нарушать ваш код. Там есть сообщение здесь Эрика Липперта, в котором объясняется, что происходит, когда вы включаете этот флаг. Прирост производительности зависит от приложения и приложения, поэтому вам нужно проверить его с вашим проектом, чтобы увидеть, есть ли какие-либо заметные различия (с точки зрения производительности).

Ответ 3

Возможно, что некоторые ошибки возникнут при запуске в режиме выпуска, которые иначе не встречаются. Признается печально известный "нелетучий флаг":

flag = false;

Thread t = new Thread(
   o =>
   {
        while(!flag)
        {
           // do stuff
        }
   });
t.Start();

// main thread does some work

flag = true;
t.Join(); // will never return in release mode if flag is not volatile

Это происходит из-за оптимизации компилятора, поскольку переменная флага получает кеширование ядром потока t и, следовательно, не может видеть обновленное значение флага.

Ответ 4

Должны ли оптимизации вводить ошибки? Нет.

Может ли оптимизация вводить ошибки? Может быть, ничего идеального в конце концов.

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

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

Ответ 5

В С# оптимизация должна НИКОГДА не нарушать ваш код.

Вместо этого при включении оптимизаций компилятор создает более компактный CIL при переводе между С# и CIL.

Я заметил (и, откровенно говоря, интересно!), что компиляторы С# из .NET < 2.0 (1.0 и 1.1), созданные как хорошие оптимизаторы CIL WITHOUT, поскольку более поздние компиляторы С# (2.0 и более поздние) производят с оптимизацией.

Ответ 6

Пример. У меня есть часть кода из некоторых частей моделирования моей магистерской диссертации. В котором с включенным флагом оптимизации код действительно не разрывает программу, но в pathfinder выполняется только один проход и циклы. (рекурсивный код перехватывает себя в цикле на pathfinder, который он всегда выходит из строя с выключенным флагом оптимизации).

Итак, да, возможно, флаг оптимизации может сделать поведение программного обеспечения по-разному.

Ответ 7

Оптимизация компилятора

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

for (int i = 0; i < list.Count-1; i++) {
  list[i+1].DoSomeThing();
  //some code
  if (someCondition) {
    list.insert(i+1, new Item());
    i++;
  }
}

в какой-то момент, list[i+1] адресуется как list[i], как если бы оба указывали на один и тот же элемент. эта ошибка была настолько странной. код работал хорошо в режиме отладки и в режиме выпуска, но когда я запустил его на стороне визуальной студии, например. из файла .exe, код разбился. только отключить оптимизацию компилятора.