Оператор Javascript && против вложенных операторов if: что быстрее?

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

Мне любопытно, есть ли разница в производительности между использованием оператора && ("и") и вложенными операторами if. Кроме того, есть ли фактическая разница в обработке? То есть, && всегда обрабатывает оба оператора, или он остановит @ первый, если первый завершится ошибкой? Чем это будет отличаться от вложенных операторов if?

Примеры для ясности:

А) && ("и") оператор

if(a == b && c == d) { ...perform some code fashizzle... }

по сравнению с B) вложенными операторами if

if(a == b) {
    if(c == d) { ...perform some code fashizzle... }
}

javascript conditional-operator performance
person arxpoetica    schedule 27.06.2010    source источник
comment
Плюс один за правильную грамматику и правописание.   -  person Agent Pants    schedule 02.04.2020

Ответы (4)


arrow_upward
31
arrow_downward

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

В этом конкретном примере я бы просто выбрал тот, который использует &&, так как он лучше читается.

person BalusC    schedule 27.06.2010
comment
Не знал о принудительном & операторе. Это интересно! - person arxpoetica; 27.06.2010
comment
Обратите внимание, что & — это /побитовый/ и оператор. Думать об этом как о «вынужденной» версии && не совсем правильно. Пример: 1 && 2 равно 2, а 1 & 2 равно 0. - person Tikhon Jelvis; 27.06.2010

arrow_upward
14
arrow_downward

Если вас беспокоит производительность, убедитесь, что a==b с большей вероятностью выйдет из строя, чем c==d. Таким образом, оператор if рано потерпит неудачу.

person Gert Grenander    schedule 27.06.2010
comment
Может ли кто-нибудь пролить свет на то, почему мой ответ проголосовал против? - person Gert Grenander; 27.06.2010
comment
Я не знаю - ваше предложение кажется мне подходящим, поэтому я проголосовал за вас. - person Warren Rumak; 27.06.2010
comment
Я предполагаю, что -1 был потому, что он на самом деле не отвечает на вопрос, который был любопытным в отношении конкретной точки Javascript, а не общей оптимизации. - person Matchu; 27.06.2010
comment
@Уоррен - Спасибо. :) @Matchu - Ну, об этом уже говорили многие другие в ветке. Я просто хотел дать ему подсказку, о чем следует думать, когда речь заходит о дизайне оператора IF и его производительности. Но я ценю ваш комментарий. Спасибо. - person Gert Grenander; 27.06.2010

arrow_upward
3
arrow_downward

Как и вложенные if, && ленивы.
Выражение a && b будет вычислять b только в том случае, если a истинно.

Поэтому оба корпуса должны быть полностью идентичны как по функциональности, так и по производительности.

person SLaks    schedule 27.06.2010
comment
Вы, вероятно, имели в виду, что будет оценивать b только в том случае, если a правдиво. - person Gert Grenander; 27.06.2010

arrow_upward
3
arrow_downward

Тест производительности может помочь прояснить ситуацию: http://jsperf.com/simey-if-vs-if

Кажется, что разница в производительности между ними невероятно незначительна; Однако, как упомянул @Gert, ранняя ошибка действительно улучшает ситуацию.

person simey.me    schedule 11.05.2015
comment
Чтобы продолжить этот тестовый пример, я создал JSPerf (jsperf.com/operator-if-vs -nested-if), где вторая проверка выполняется медленнее, а первая — просто логическое значение. Это дает хорошее сравнение между парсером, игнорирующим 2-ю проверку с оператором &&, и вложением проверок. В моем тесте использование встроенного && на самом деле немного быстрее, чем вложенные ifs (но только около ~ 0,1%). - person Mark; 01.09.2018
comment
о, хорошо, Марк, твой тест гораздо яснее показывает преимущества ранней неудачи! - person simey.me; 04.09.2018