Я уверен, что это незначительно, но учитывая, что я хочу назначить true логическому полю внутри метода, делает ли этот выбор какое-либо значение? Если да, то почему?Производительность: присваивать логическое значение всегда или сначала проверить значение?
field = true; // could already be true, but I don't care
против
if(!field) field = true;
Я бы сказал, что нет. Но это зависит от того, что мы действительно говорим о поле, в отличие от объекта, который может (хотя это определенно не должно) демонстрировать различное поведение в двух фрагментах, которые вы включили (т. Е. является логикой с побочными эффектами в геттере). не
Update: Если вы говорите о потере производительности, там практически нет разностной но Я считаю, что назначение все так немного дешевле (чем чтение значения). Вот пример программы, чтобы продемонстрировать это:
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
Правильно, я только спрашиваю о полях - действительно ли назначение или проверка ценности имеют большие накладные расходы?Свойства - это еще одна история. У сеттеров также могут быть накладные расходы, например, сравнение «значение» с полем, повышение уведомлений об изменении свойств и т. Д. – Jay
@Jay: Хорошо, я думал, что «разница» означает различное * поведение *. Если мы говорим о накладных расходах, присваивание кажется (из моего собственного теста), чтобы иметь * немного * меньше накладных расходов. Я добавлю пример программы. –
@Jay Вы не сравниваете назначение и проверку ценности: вы сравниваете назначение и проверку значений, а затем, по назначению. –
Для поля, просто установите его. Для свойства это может быть более сложным, в зависимости от того, является ли get или set непропорционально дорогостоящим, и/или проверяет ли это set внутри него (минуя события и т. Д.).
Как правило, для свойств просто установите его, пока не узнаете, что это проблема из-за профилирования.
Для полей; не беспокойтесь о нем чрезмерно; по умолчанию.
Конечно, свойство, которое занимает значительное количество времени для 'set' (и не проверяет, будет ли оно избыточным), является либо WTF, либо чем-то очень редким с очень хорошими рассуждениями. – delnan
Что я обычно делаю, если я ожидаю чего-то другого, кроме значения по умолчанию для любого типа переменной, я устанавливаю его в то, что обычно не будет. Таким образом, если значение не изменилось, тогда я знаю, чего ожидать и как его обрабатывать. Это не было бы действительно применимо к вашим примерам, ваш вопрос нечеткий, ваши примеры не объясняют, что вы пытаетесь сделать.
Я согласен с заявлениями Марка и Дэна, конечно.
Еще в 90-х годах, когда я программировал на ассемблере x86, правило было (IIRC), чтобы избежать переходов. Утверждение if было бы реализовано как прыжок.
Так что мой вывод был бы (при от предположения, что по крайней мере некоторые тех древних правил все еще применяются), что позволяет избежать if и назначения непосредственно будет более производительным.
Я согласен с вами, я уверен, что это ничтожно! Серьезно, хотя вопрос гораздо более интересный, который более ясен и так легче поддерживать. –
, и что касается вашего фактического вопроса, два разных пути в версии с if будут занимать разные времена, поэтому вы не можете ответить, не зная вероятности появления каждого пути. Это говорит, что мне будет трудно поверить, что обычное безусловное задание будет избито. –
Если у меня есть такая проблема, я буду использовать первого, кто заботится о производительности в этом случае, это ваше соглашение. –