Короткое замыкание и производительность - PullRequest
1 голос
/ 11 августа 2011

Большинство языков используют короткозамкнутые и / или операторы. Например

return foo() && bar();

никогда не вызовет bar (), если foo () вернет false. Нет необходимости вызывать bar (), если мы знаем, что результат выражения в любом случае будет ложным.

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

Так что мне интересно: это все еще увеличение производительности для операторов короткого замыкания?

Ответы [ 2 ]

1 голос
/ 09 января 2013

Ответ должен быть «возможно».

Взгляните на этот блог Эрика Липперта о некоторых низкоуровневых оптимизациях, выполняемых компилятором C #.

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

Вкратце: разве это не должно быть temp1.HasValue && temp2.HasValue? Обе версии дают одинаковый результат; Является ли короткое замыкание более эффективным? Не обязательно! И в совокупности два bools работают чрезвычайно быстро, возможно, быстрее, чем выполнение дополнительной условной ветви, чтобы избежать чрезвычайно быстрого поиска свойств. И код, конечно, меньше. Roslyn использует не закорачивающее AND, и я, кажется, напоминаю, что более ранние компиляторы также.

1 голос
/ 11 августа 2011

да.

Подумайте об этом, что если вы захотите сделать что-то вроде этого:

return IsOKToStart() && CalculateFirstPrimeGreaterThanTrilion();

первый - простой тест, другому все еще потребуется несколько месяцев для вычисления.

...