Анализ if-операторов для оптимизации производительности

Question

Выполняется ли в C# все операторы if перед выполнением, чтобы в случае, если оператор if не может быть правдой (до подтверждения всех условий), будет отменен?

Моя проблема в том, что я хочу избавиться от нескольких операторов if, потому что некоторые методы в операторе if требуют долгого выполнения (что теряется впустую, если они были выполнены).

Вот простой оператор if (здесь он работает). Но насколько это хорошо на сложных заявлениях?

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
using System.Threading; 

namespace IfTest 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      if (true || NeedALongTime()) 
      { 
       Console.WriteLine("!"); 
      } 

      Console.ReadLine(); 
     } 

     private static bool NeedALongTime() 
     { 
      Thread.Sleep(10000); 

      return true; 
     } 
    } 
} 

Answer 1

Метод NeedALongTime никогда не будет называться. C# перестает оценивать логическое выражение, как только оно сможет определить результат.

Это называется короткозамкнутым и не связано с каким-либо анализом. Так язык оценивает логические выражения. Если вы использовали метод, возвращающий true вместо значения true, короткое замыкание все равно будет работать, и NeedALongTime не будет вызываться.

Языки, подобные C# и C++, используют короткое замыкание, в то время как другие, такие как VB.NET, этого не делают.

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

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

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

Answer 2

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

Это называется короткое замыкание. Это гарантированное поведение.

Это не оптимизация компилятора или JIT.

Вы можете положиться на это, но, на мой взгляд, он делает для хрупкого и подверженного ошибкам код, чтобы сделать это по соображениям производительности. Для будущих сопровождающих может быть непонятным, почему порядок оценки имеет, чтобы быть таким образом, хотя, похоже, нет очевидных зависимостей. Может быть, вы можете использовать Lazy<T>, чтобы получить ленивую оценку ?!