Подтвердить что ты не робот

Производительность: всегда назначать логическое значение или сначала проверять значение?

Я уверен, что это незначительно, но учитывая, что я хочу назначить true логическому полю внутри метода, делает ли этот выбор какой-либо разницы? Если да, то почему?

field = true; // could already be true, but I don't care

против

if(!field) field = true;
4b9b3361

Ответ 1

Я бы сказал, нет. Но это зависит от того, что мы действительно говорим о поле в отличие от свойства, которое может (хотя это определенно не должно) демонстрировать другое поведение в двух фрагментах, которые вы включили (т.е. Если есть логика с побочными эффектами в геттере).

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

bool b = false;

Stopwatch sw = Stopwatch.StartNew();
for (int i = 0; i < int.MaxValue; ++i)
{
    b = true;
}
sw.Stop();

TimeSpan setNoCheckTime = sw.Elapsed;

sw = Stopwatch.StartNew();
for (int i = 0; i < int.MaxValue; ++i)
{
    // This part will never assign, as b will always be true.
    if (!b)
    {
        b = true;
    }
}
sw.Stop();

TimeSpan checkSetTime = sw.Elapsed;

Console.WriteLine("Assignment: {0} ms", setNoCheckTime.TotalMilliseconds);
Console.WriteLine("Read: {0} ms", checkSetTime.TotalMilliseconds);

Выход на моей машине:

Assignment: 2749.6285 ms
Read: 4543.0343 ms

Ответ 2

Для поля просто установите его. Для свойства это может быть более сложным, в зависимости от того, является ли get или set непропорционально дорогостоящим и/или проверяет ли это set внутренне (минуя события и т.д.).

Как правило, для свойств просто установите его, пока вы не узнаете, что это проблема из-за профилирования.

Для полей; не беспокойтесь о нем чрезмерно; по умолчанию.

Ответ 3

В 90-х годах, когда я программировал на ассемблере x86, это правило было (IIRC), чтобы избежать переходов. Инструкция if была бы реализована как прыжок.

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

Ответ 4

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

Я согласен с заявлениями Марка и Дэна, конечно.