Производительность: всегда назначать логическое значение или сначала проверять значение? - PullRequest
18 голосов
/ 03 января 2011

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

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

против

if(!field) field = true;

Ответы [ 4 ]

16 голосов
/ 03 января 2011

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

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

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
10 голосов
/ 03 января 2011

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

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

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

5 голосов
/ 03 января 2011

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

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

0 голосов
/ 03 января 2011

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

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

...