Сравнение логического значения перед его установкой

Question

В C #, при установке значения логической переменной на false только , когда оно равно true, следует ли мне проверять, является ли оно true, перед установкой или просто установить его?

Предполагая, что переменная равна true 50% времени, проверка имеет смысл, поскольку сравнение выполняется быстрее.Если в большинстве случаев переменная равна true, следует ли мне просто пропустить сравнение?

Какая практика лучше?

Метод 1, сначала проверка:

if (bVariable)
    bVariable = false;

или Метод 2, Просто установите его:

bVariable = false;

При каких условиях метод 2 предпочтителен, если вообще?

Answer 1

С чего вы взяли, что сравнение происходит быстрее?Если код, который вы пишете, был выполнен в компиляторе C, оператор IF разделился бы как минимум на две инструкции - инструкцию сравнения / ветвления и инструкцию "set" для одного бита одного слова.

"set" будет компилироваться в одну инструкцию.Ваша «оптимизация» может замедлить работу вашей программы и сделать вашу программу менее читаемой.Просто установите переменную и не пытайтесь продумать мелочи.

Процессоры не похожи на базы данных.Вы не платите большие штрафы за изменения данных. Вы платите большие штрафы за поездки в основную память и за ветвление (если операторы).Ветвления стоят производительности, потому что конвейерная обработка ЦП фактически начинают выполнять инструкции после ветвления, прежде чем инструкции ветвления даже примут свое решение!(Я знаю, это утверждение несколько ошеломляет).Но это означает, что ЦП должен тратить ресурсы " угадывая ", каким будет результат вашего утверждения IF.Если он угадает неправильно, он должен «выбросить» результаты всех предполагаемых им инструкций, которые будут выполнены после ветвления, и повторить попытку.Это плохо.Вот почему филиалы стоят дорого.

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

На самом деле, если вы действительно заинтересованы в подобных вещах, вам следует определенно взять копию Code Complete .Он полон дискуссий о подобных вещах и великолепно написан.

Answer 2

В C # ответ: метод 2 всегда предпочтителен. Поскольку это очень простая оптимизация, если бы метод 1 был действительно быстрее, компилятор сделал бы это.

EDIT:

У Дональда Кнута есть несколько советов против вашего метода 1, например, «преждевременная оптимизация - корень всего зла» и «код предназначен для того, чтобы его сначала читали люди, а вторые машины».

Answer 3

Не усложняй жизнь.Просто установите это.Во всяком случае, на самом деле проверять сначала дороже, так как теперь вам нужно отбросить существующее значение из ОЗУ (или кеша) перед отправкой нового значения.

(С помощью Колина Маккея ...) Сначала тестированиетакже влечет за собой штрафы за остановку трубопровода из-за неправильных прогнозов ответвлений.

Answer 4

Метод 2 следует отдавать предпочтение просто потому, что он выражает тот же результат более просто, облегчая его чтение, как говорили другие, - для чего-то простого, такого как эта разборчивость, гораздо важнее, чем стремительно малая проблема производительности.

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

Answer 5

Я бы сказал, что разница в производительности настолько незначительна, просто постоянно устанавливайте значение false.

Если оно равно false, оно снова будет установлено в значение false.Если оно истинно, оно будет установлено в ложь.

В конце кода переменная будет ложной, независимо от того.

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

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

Answer 6

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

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

Answer 7

Проблема с производительностью здесь не актуальна, потому что простое утверждение if, подобное приведенному выше, по существу близко к запрету работы процессора. Гораздо важнее, чтобы ваш код четко сообщал о своем намерении будущим читателям!

Thomas

Answer 8

Преждевременная оптимизация - корень всего зла.Невозможно убедить меня, что эта «оптимизация» даст вам любой прирост производительности при всех

Answer 9

Единственная причина для сравнения заключается в том, что если у вас есть дополнительная логика, которую нужно выполнять при изменении значения.

Если вы все равно будете назначать его, это, скорее всего, ухудшит производительность, если вы это сделаетедополнительный чек.